symfony bundle

[dbu]

is there already a symfony bundle for php-http that either uses the locator or can be configured to an explicit client adapter / message factory?

[dbu]

and if not, could you imagine having one in the php-http organisation if i contribute it?

[dbu]

i just found that @egeloen is still pushing things to https://github.com/egeloen/IvoryHttpAdapterBundle - now i am confused. is the ivory http adapter not obsoleted by the php-http adapter?

[sagikazarmark]

Absolutely. Symfony Bundle is planned. However php-http is not yet stable, this is why:

• there is no bundle yet
• @egeloen still maintains Ivory adapter

Many projects rely on the "old" package, which is currently stable (or close to it). This project is not yet stable, but already has some stuff to play with. However, there are still many work to be done, even at the abstraction level (see php-http/httplug#38).

At some point php-http will replace ivory http adapter (I would say mid-autumn).

If you would like to work on a symfony bundle, I can create you the repository with the basic content based on our boilerplate, so you can start working on it. Is that fine for you?

[dbu]

cool, thanks for the infos! my idea for the bundle would be to provide a service with each of the adapters / factories that by default uses the ::find mechanism but instead can be configured to an explicit class. additionally, we might provide a request listener that comes very early and register a class for some of the discoveries in case some libraries rely on discovery only.

this is not a big thing, but i feel every symfony bundle would have to repeat that and users would have to repeat configuration several times.

by allowing to configure a totally custom client adapter service id that we alias to php_http.client or something like that, the user can also configure his guzzles or whatnot as he needs.

does that make sense? if that is about the scope of the bundle, i would be happy to contribute a first draft of that. for FOSHttpCacheBundle we will need that... i guess the repo name according to symfony naming conventions would be PhpHttpBundle.

[sagikazarmark]

It absolutely make sense. Static discovery should be the last thing you use. As said, the point is zero config, but in a framework integration it can probably solved better.

Actually PhpHttp is rather a vendor name. It should be HttpAdapterBundle or HttpClientBundle. We are currently doing some cleanup in the terminology (see php-http/httplug#38). The plan is to have more generic interface names (like HttpClient instead of HttpAdapter). While the interfaces will be generic, the discovery classes will still be adapter specific.

[dbu]

the naming idea makes a lot of sense. the correct name then might be PhpHttpClientBundle. the thing is that just HttpClientBundle is really generic - on the other hand its a statement that this is the thing to use :-)

i was thinking of PhpHttpBundle because i would integrate all things available in discovery into one bundle. having one separate per type (client adapter / message factory / uri factory) seems like overkill.

[sagikazarmark]

Well, we us Http as a namespace. The idea behind the organization is to collect everything that is useful and related to HTTP. While the client/adapter is our main "product", we don't want to be limited to it.

That's the reason why I think PhpHttpBundle would be a bad choice, but I agree that the mentioned things should be under one bundle. On the other hand, this adapter thing IS our main project, so probably using the vendor name for its bundle is not so bad.

[dbu]

well the github organisation is called php-http... naming things really is one of these difficult challenges :-)

but as long as we agree on what it should do, i let you have the call on the name. HttpClientBundle could be fine - in the end the Request factory and Uri factory are just sub-problems of having a http client.

[sagikazarmark]

Agree.

If you start working on something: take a look at our boilerplate repository (be aware of the separate branches). That should give you a picture about how we organize packages.

[dbu]

agree on the name? of course we can still fix it later, but if we can avoid renaming i won't mind :-)

i can start in a repo in my organisation and later transfer the repo to php-http if you want. or you could create a repo directly here and give me access to it. as you prefer.

[sagikazarmark]

Agree that naming is hard. And agree on naming. Lets call it PhpHttpBundle. We can still rename it if we have to, but I cant come up with a better name right now. Feel free to start it in your repository.

[dbu]

created https://github.com/dbu/HttpClientBundle - happy for input on the issues i created