Implement remaining adapters about httplug HOT 44 CLOSED

from httplug.

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

from httplug.

from httplug.

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.

from httplug.

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.

from httplug.

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.

from httplug.

from httplug.

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

from httplug.

@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).

from httplug.

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

from httplug.

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

from httplug.

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

from httplug.

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 ?

from httplug.

Yes, there is, it is called boilerplate.

from httplug.

I updated the list, to reflect the ones under 1.0.0

from httplug.

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?

from httplug.

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.

from httplug.

Updated the list

from httplug.

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.

from httplug.

is stopwatch not also a plugin thing?

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

from httplug.

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);
    }
}

from httplug.

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.

from httplug.

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 😄

from httplug.

@shulard awesome. 👍 Will definitely review it.

from httplug.

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.

from httplug.

👍

Created repo, added you @shulard, Travis setup

from httplug.

Thanks, I'll start migration now 😄

from httplug.

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

from httplug.

Updated the list

from httplug.

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

from httplug.

👍

from httplug.

@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.

from httplug.

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.

from httplug.

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

from httplug.

Ultimate Web Scraper Toolkit is missing from this list.

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

from httplug.

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.

from httplug.

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

from httplug.

@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.

from httplug.

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

from httplug.

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

from httplug.

@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...

from httplug.

Cakephp and Zend2 adapter available,

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

from httplug.

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

from httplug.

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?

from httplug.