Why not a http adapter library?

[sagikazarmark]

I am just asking: why not using a HTTP adapter library? @toin0u IIRC you pointed me to ivory http adapter, I was surprised when I saw it isn't used in the library.

[toin0u]

@sagikazarmark It's because I started this lib before I knew about IvoryHttpAdapter. I think it can be good to change it :)

[GrahamCampbell]

@toin0u I don't think IvoryHttpAdapter is mature enough to switch to yet. I think we should wait it to mature and stabilize. Probably wait for a 1.0 release on that repo.

[toin0u]

@GrahamCampbell I see your point and it makes sense but we're already using it in the coming Geocoder 3.0 :) What do you think @yassirh @sagikazarmark @liverbool ?

[yassirh]

I'm not really sure. i have never used it before so i would have to take a look and then say. just a quick question... what are the advantages for switching ?

[liverbool]

+1 to use adapter.

[sagikazarmark]

You are already using some sort of adapter packed in this library. The difference is that ivory has much mor implemented HTTP clients.

However it must be noted that it uses PSR 7, which changes every day.

[yassirh]

👍 from me too. however would it be safe to use it while it is still in an early development stage?

[sagikazarmark]

I would say it is stable enough to use. As @toin0u said, Geocoder is already using it. The underlying PSR7 standard is unstable ATM, but the adapters API will remain the same I think.

[toin0u]

@egeloen follows PSR-7 closely and is very active to update its package if needed :) We do not have any issue with the lib in Geocoder (alpha1).

[sagikazarmark]

Hey guys,

I would like to give you some up-to-date information.

Today we tagged HTTPlug 1.0.0-beta.

Two questions might arise immedately: Who are "we"? What is HTTPlug?

By "we" I mean the PHP HTTP Team. @egeloen and I started it. At the first time we wanted to stabilize the adapter package, separate it into smaller components. After half year of work HTTPlug was born. New members joined the team, and projects started to get involved (FOS HTTP Cache, FXMLRPC to name a few).

HTTPlug is the successor of ivory HTTP Adapter.

If you are still interested in this, check our documentation: docs.httplug.io or follow us on twitter.

[sagikazarmark]

@GrahamCampbell why is this closed without explanation?

[GrahamCampbell]

We simply don't need it. Our adapters work just fine, and I don't think we should bother trying to support numerous other libraries.

[xabbuh]

@GrahamCampbell But this would force me to install more than one HTTP client library if I wanted to use this package and I am already using another HTTP client library for other code in my application.

[GrahamCampbell]

Yes, it would. Most people use one of guzzle 3->6 or buzz though. That covers most bases.

[xabbuh]

Honestly, I don't understand why you insist on implementing features in this package (i.e. adapting HTTP client libraries) which is not part of the package's core domain when there is a library that does this job quite well.

[GrahamCampbell]

I may review this again in a year once this situation has matured, since this library was already moved about and stuff changed.

[sagikazarmark]

when there is a library that does this job quite well.

Well, it is not stable yet, so any concerns regarding stability might be acceptable. Also, our "marketing" side was probably not the best in the past, but as we are closing to a stable release, we will definitely improve this.

Apart from that, I agree with @xabbuh.

Our interfaces are pretty stable now, we are cleaning up implementation details which means that the project itself is ready for community reviews and test runs.

[GrahamCampbell]

As I said, I'll review this in a year's time, and if people are actually adopting this, and it looks solid, then I'll seriously consider moving to it.