Diactoros support

[shadowhand]

Any reason that diactoros isn't supported for discovery?

[sagikazarmark]

It is supported:

https://github.com/php-http/message/blob/master/src/MessageFactory/DiactorosMessageFactory.php

It is automatically discovered when php-http/message is installed thanks to Puli.

[shadowhand]

It's not listed on http://php-http.org/en/latest/clients.html

[sagikazarmark]

Not sure I can follow. Diactoros is a message implementation, not a client.

Although it seems that the actual documentation for Guzzle and Diactoros factories are got lost in the middle of conversion to RST. /cc @ddeboer

It is mentioned here:
http://php-http.org/en/latest/message.html

[dbu]

i think it was never on that page. with the title of "Clients & Adapters", we should link to the message factory implementations page - reading the TOC when not too familiar with the naming, its not clear that messages are somewhere else and this is only about HTTPlug adapters.

[shadowhand]

Okay, that makes sense but it's really not clear at all. The docs should really have a table that shows all of the supported PSR-7 implementations and what kind of support they include. The headings would be something like:

Project	Client	ServerRequest	Request	Response	Stream	Uri	FileUpload
Guzzle5	x	-	x	x	x	x	x
Diactoros	-	x	x	x	x	x	x

[sagikazarmark]

That's a good idea.

One question though: how is client related to the message implementation? Those are two separate things.

(Also, I guess it is Guzzle 6, right?)

[shadowhand]

I see "client" as a separate designation to make it clear that the adapter supports sending HTTP requests, not just generating them. As you said, Diactoros is not a HTTP client but Guzzle is.

Personally I still find HTTPlug pretty heavy to abstraction. I think a lot would be gained by making the code less "smart" and having more hard-coded aliases in place.

[dbu]

@shadowhand good idea! do you want to do a PR to add a page "Message Factory Implementations" in the Message section and add this table there? it should link to the factory concept explanation and then have this table you proposed and the class names for those factories.

@sagikazarmark "how is client related to the message implementation": before i started contributing to php-http, i would not have been able to spot the difference between guzzle the http client and guzzle the (psr7) request / response implementation. its kind of not-obvious to separate them. (i agree it technically makes sense, but the doc needs to help avoid the confusion).

[dbu]

re: abstraction: i don't see how HTTPlug could not be abstract - it only an interface about sending psr requests and returning psr responses which are described purely as interfaces. when you write an application, this might well be enough abstraction for you, and you can do new Guzzle\Psr\Response (or whatever the exact namespace is). when writing a reusable library that needs to do http requests, you really want the abstraction to avoid binding to a specific message implementation. you want the factory and HTTPlug injected and only use those. then users of the library can choose both client and message implementation themselves.

[dbu]

but if you have concrete cases where a php-http part tries too much to be "smart", please point them out. now we can still fix things, and if we can simplify without creating hard limits, i am all for it.

[shadowhand]

Using Puli for example... just adds a whole new layer of abstraction that really doesn't need to be there.

[dbu]

well, discovery in itself is a tricky business. with puli, there is at least a decent solution if one wants to do it.

but i think most of the time, rather than using discovery, you want to instantiate the correct client, adapter and factory yourself and inject that in your classes. or use the HttplugBundle when using symfony. in those situations, you don't need php-http/discovery at all.

[shadowhand]

Why isn't it as simple as having a list of supported classes and searching for one that is available?

[sagikazarmark]

That was the initial plan, but that required maintenance and it was less flexible.

With puli, it is enough to place a puli.json in the package root and discovery will find it. No need to maintain a static list of resources and it even works with your custom implementations, which wouldn't make it to the core repository anyway.

[shadowhand]

Sure it would require a minimal amount of maintenance. I'd take that over the overhead of Puli.

It's very possible to write discovery code that also allows custom implementations to be injected.