Implement remaining adapters

[sagikazarmark]

• Guzzle 6 (Implemented by @ddeboer)
• Guzzle 5 (Implemented by @sagikazarmark and @Nyholm)
• Guzzle 4 (EOL)
• Guzzle 3 (EOL)
• Curl (Implemented by @mekras)
• Buzz (Implemented by @Nyholm)
• Cake (Implemented by @joelwurtz)
• HTTPful (Not important at the moment)
• PECL (Not important at the moment)
• React (Implemented by @shulard)
• Socket (Implemented by @joelwurtz)
• Zend 1 (too old)
• Zend 2 (Implemented by @joelwurtz)
• File get contents (?) (Not important at the moment)
• Fopen (?) (Not important at the moment)
• League Event (decorator) (Hard to use with immutable messages)
• Symfony Event (decorator) (Hard to use with immutable messages)
• Stopwatch (decorator) (Implemented as plugin)

[ddeboer]

For Guzzle, have a look at Version Guidance: 3 and 4 are EOL, so no use to create adapters for those.

cURL: I’m not sure this is needed either. Creating an adapter for the raw PHP cURL functions is a bit like writing your own client, such as Guzzle.

[sagikazarmark]

Yeah, the question mark meant that I am not completely sure we should support 3 and 4.

About cURL: Not sure about that either. One possible reason for it is that you don't have to install any HTTP clients, only the curl extension.

[willdurand]

A shortcut would be to support ivory-http-adapter, it does the job really well, and have been in use in rather large projects for months now.

[dbu]

we know of ivory. this library was built in collaboration with @egeloen and is intended to replace the ivory adapter. the original code was ported from ivory and the idea is to do the same with the adapters.

[willdurand]

Ah cool. Would be cool to have that written somewhere maybe, to avoid comments from people like me, fighting NIH syndrom :(

[sagikazarmark]

@willdurand it is mentioned in the docs (implicitly). http://php-http.readthedocs.org/en/latest/

But thanks for the feedback. We should definitely improve our documentation, but so far the priorities were actual work on interfaces. Now, that we are close to release, we should start working on improving it.

So far @dbu worked on that (and he did a great work).

[willdurand]

I apologize, I missed this part in the doc. I'm looking forward to using it in Geocoder.

[sagikazarmark]

@willdurand no need to apologize, I am also against NIH.

[dbu]

thanks @willdurand for not just shouting at us for NIH. i think this is important, adding a note to the README to clarify : #67

[shulard]

Wow, your lib seem really interesting I look forward to use it 👍

I've experience with cURL and I think I can start working on it but is there a way to start a new adapter project ? boilerplate ?

[sagikazarmark]

Yes, there is, it is called boilerplate.

[joelwurtz]

I updated the list, to reflect the ones under 1.0.0

[dbu]

i am -1 on fopen / file_get_contents clients, we should focus on adapters for popular and high quality clients and make the socket and curl implementations work well.

are the decorators not rather a topic for plugins?

[sagikazarmark]

i am -1 on fopen / file_get_contents clients

Agree. We already discussed this somewhere, but haven't updated the issue yet.

are the decorators not rather a topic for plugins?

They are. AFAIK @joelwurtz started to work on some of them. However not all should be implemented at all. For example even't driven architecture is not an option anymore hence the immutable nature of messages.

[sagikazarmark]

Updated the list

[dbu]

if i got it correctly, plugins can change the request / response, so events could be used theoretically. but its a plugin topic. is stopwatch not also a plugin thing? of course its a thing where priority matters, but i think it would be fine as a plugin.

[joelwurtz]

is stopwatch not also a plugin thing?

Already implemented as a plugin so yes, adapter / client are only thing that really do http calls

[sagikazarmark]

so events could be used theoretically

You are right. But in practice you would have to do something like this:

class Listener
{
    public function listen (Event $event) {
        $request = $event->getRequest();

        //...do something

        $event->setRequest($request);
    }
}

[dbu]

at least in symfony, this is a common pattern. but this would be a topic for the bundle. while it sounds flexible and whatnot, in the end, i think its pointless. the event listener would still know about the httplug bundle event class. at that point, it can just as well be a plugin that knows about the httplug plugins system. there is no added flexibility with the events.

[shulard]

Hello guys, I finished an implementation for the ReactPHP lib.

You can find my code here: https://github.com/shulard/httplug-react-client

I've used the bootstrap project to start my code and the test suite for Sync and Async passed well. Can you review it and tell me if it'll be fine to add inside php-http.

Thanks 😄

[sagikazarmark]

@shulard awesome. 👍 Will definitely review it.

[dbu]

great! i gave some feedback in shulard/httplug-react-client#1

i suggest we create a react-adapter repository here (that would match guzzle6-adapter and the others for the naming) and move the code over. and @shulard would get commit rights on that repository.

[sagikazarmark]

👍

Created repo, added you @shulard, Travis setup

[shulard]

Thanks, I'll start migration now 😄

[shulard]

Hello I've updated the react adapter with the CS Fixer configuration. I think we can consider this adapter done 😄.

[joelwurtz]

Updated the list

[egeloen]

If nobody is working on the Zend 2 adapter I will take it :)

[sagikazarmark]

👍

[egeloen]

@sagikazarmark I know I'm very late in the party... :) Which adapter can be currently considered as done? (Just to start my implementation according to it). I will start based on the boilerplate package but it is much more to see how it has been implemented.

[sagikazarmark]

Guzzle 6 is somewhat done, it is considered to be the PoC implementation. However there are some ongiong changes (see open PRs) which haven't been accepted yet.

[egeloen]

Okay thanks for the feefback! Will see them and come back here if I have some questions.

[cubiclesoft]

Ultimate Web Scraper Toolkit is missing from this list.

https://github.com/cubiclesoft/ultimate-web-scraper/

[sagikazarmark]

Not sure if it actually would be an adapter or this library could be a consumer of HTTPlug. Also, it has no composer support which would make things a little bit hard.

[cubiclesoft]

The WebBrowser/HTTP classes of that project are in the same relative universe as Guzzle and cURL, so it would be an adapter. Only those parts of the library would be used. If you use the async bits, you'll need a little more glue.

Composer support here:

https://packagist.org/packages/cubiclesoft/to-composer

[dbu]

@cubiclesoft you are welcome to build an adapter library for the cubicle web browser (at cubiclesoft/httplug-adapter maybe?) and do a pull request against the php-http documentation so that we list your adapter.

[joelwurtz]

CakePHP : https://github.com/php-http/cakephp-adapter

[joelwurtz]

@egeloen I know you wanted to do the zend http adapter, is there anything ? Do you mind if do it ?

[egeloen]

@joelwurtz I have started to work on it but it was more complex than simply porting the code from the previous Ivory adapter... AFAIR, during my last try, I got issues related to tests which do not pass...

[joelwurtz]

Cakephp and Zend2 adapter available,

Do you think it still make sense to do a zend1 adapter ?

[dbu]

Do you think it still make sense to do a zend1 adapter ?

i'd recommend not to do that. if somebody desperately needs one, they can donate it to php-http if they want, but zend framework is at version 3 by now afaik, so 1 is really legacy...

[joelwurtz]

Zend3 does not have a http client (it uses one from zend2)

[dbu]

right. but anyways, lets not do a zend 1 adapter.

[sagikazarmark]

There are two remaining adapters: HTTPful and PECL. Are these mature enough to provide official adapters for them? Personally I never used them. Also, if someone wants to implement it in the future, I won't say no.

WDYT?

[dbu]

imho we can close this issue and just see if somebody wants to contribute those adapters