Closed mateuszsip closed 5 years ago
Hello,
We are happy to see you RFC. It's great idea to make SMSAPI PHP Client more dependency-independent, but our team discussed about it and we are decided to use PSR-18 instead of HTTPlug. PSR-18 is still in review stage, but we think there shouldn't be any break of backward compatibility. Considering the above I believe it's not worth implementing HTTPlug. However, if you are still eager to be involved in development of SMSAPI PHP Client we are happy to see your PR for PSR-18.
Please, be aware that we are going to release v2 in few weeks.
Nice, great to see that PSR-18 is alive!
I did some basic research about available implementations, and we have 2:
And we need to choose one for tests, and give library users some tips about migration. Because they will have to choose something from this list.
HTTPlug will make it easy because of existing guzzle adapter. It's not stable yet, but they want to release 2.0 this month. Coincidence? 😄 So this would be recommended implementation for guzzle users.
I will do my best to prepare PR as soon as possible, so we can merge it before v2 of your library, after HTTPlug 2.0 is stable.
What do you think?
I agree with you, HTTPlug 2.0 it's good choice.
We will wait for your PR.
Hi. What do you think about replacing explicit Guzzle dependency with HTTPlug?
HTTPlug is an http client abstraction meant especially for libraries, to avoid binding to specific implementation so teams using your library can choose their favorite implementation without risk of getting version conflicts. So it makes life easier.
I can prepare a PR, but wanted to ask first.