Hi, I'm glad to see that you raised similar questions.
It definitely makes sense to make some research on this topic and find out differences in most popular implementations. Just another my 2 cents... If there are multiple implementations with different validation and all these implementations strictly respect PSR-7, then PSR-7 has "white spots". In makes things more implicit, harder to replace one implementation with another one. If there are multiple implementations, but they are not strictly respect PSR-7, then they violate the Liskov substitution principle. There is no excuse for such violations even for "performance reasons" and "memory usage". After all, it's not hard to make official PHP extension. On Friday, June 24, 2016 at 12:37:53 AM UTC+3, Matthieu Napoli wrote: > > Hi Daniel, > > I think this is an interesting question, for reference here is a thread > last month about it: > https://groups.google.com/forum/#!topic/php-fig/u2Nmovw_Rlc > > If there are specific reasons for multiple implementations then maybe it > would make sense to collect them in PSR-7's meta-document? That way it will > be documented. If there are no reasons, then maybe it's worth discussing > standardizing an implementation? > > Matthieu > > Le mardi 21 juin 2016 10:15:59 UTC+2, Daniel Plainview a écrit : >> >> > Guzzle has traditionally focused on client behavior, and has >> optimizations around memory usage and generator driven streams; streams are >> its particular strength. Diactoros and Slim focus on server side details, >> with the former being a full, general purpose implementation, and the >> latter only implementing the server request and response (IIRC). >> >> It means that they are not fully compatible. Guzzle allows arbitrary >> header name, for example. >> It's harder to trust another implementation if they are behaves >> differently like *this*. >> Also it's not clear for me that Guzzle ignores validation on purpose. >> Maybe it's a bug. :) >> >> > Where I'm seeing differentiation is around convenience features. As an >> example, specialized response types for json, html, XML, or even callable >> or iterator streams. Additionally, populating a server request typically >> requires a factory, and that detail will change based on whether you're >> using an SAPI or an async server. >> >> It's like saying that >> final FryGotFrozenAt extends \DateTime >> { >> public function __construct() { >> parent::__construct('1999/12/31 18:00:00 UTC'); >> } >> } >> >> is different implementation of DateTime. >> But I think it's not concern of Request/Response objects to work with >> different formats. >> Sooner or later you may come to request/response-as-a-service with DI >> dependencies, configuration, etc. >> I don't this that having XmlResponse is an advantage, I see the opposite. >> You can fill your request/response objects in different layers. >> >> > This is not s valid comparison. Each of these projects predates psr-7, >> and adding psr-7 support cannot be done without breaking backwards >> compatibility. >> Exactly what I tried to say. Almost all existing (pre-PSR-7) libraries >> are not compatible; every new future implementation will be very similar to >> other ones. >> >> > Considering we have multiple implementations that do differ, and which >> are now generating errata due to differences observed, I disagree with your >> assertion. >> >> Of course you will see differences, but the question is if these >> differences are "true" and "valid"? >> They differ in terms of lack of validation (if you mean that case with >> withHost()). >> It reveals design issue: they shouldn't differ here; they should behave >> the same. >> >> On Tuesday, June 21, 2016 at 6:59:13 AM UTC+3, Matthew Weier O'Phinney >> wrote: >>> >>> >>> On Jun 20, 2016 3:47 PM, "Daniel Plainview" <daniel...@gmail.com> wrote: >>> > >>> > Hello, >>> > >>> > The one thing in PSR-7 still bothers me: do different implementations >>> truly exist? >>> >>> Of the top of my head: Diactoros, Guzzle, and Slim, and I've read of >>> others working on additional implementations. >>> >>> > Or in other words: how these implementations may differ in terms of >>> behaviour? >>> >>> Guzzle has traditionally focused on client behavior, and has >>> optimizations around memory usage and generator driven streams; streams are >>> its particular strength. Diactoros and Slim focus on server side details, >>> with the former being a full, general purpose implementation, and the >>> latter only implementing the server request and response (IIRC). >>> >>> league/uri provides an implementation of the UriInterface only, and is >>> the most thorough implementation I've seen. >>> >>> Each is addressing particular elements that are of specific interest to >>> their projects and intended use cases. The basic functionality is the same, >>> but some features and approaches differ. >>> >>> > If they don't really exist, so why PSR-7 doesn't provide >>> Request/Response classes? >>> > >>> > I'll try to bring my point through imaginary dialog. >>> > >>> > — You don't like interfaces? Program to an interface, not an >>> implementation, Luke! >>> > >>> > PSR-7 provides the set of interfaces for HTTP-messages. >>> > Yes, "program to an interface, not an implementation" is the first >>> thought. >>> > But sometimes different implementations don't make much sense. >>> > Usually, one-to-one interfaces make no sense for value objects and >>> entities. >>> > If value object behaves differently in the same use cases, you >>> probably work with different concepts. >>> >>> Where I'm seeing differentiation is around convenience features. As an >>> example, specialized response types for json, html, XML, or even callable >>> or iterator streams. Additionally, populating a server request typically >>> requires a factory, and that detail will change based on whether you're >>> using an SAPI or an async server. >>> >>> So, yes, there's definitely room for multiple implementations, even when >>> programming to an interface. >>> >>> > >>> > You always expect that DateTime('2000/12/31') + 1 day gives us >>> DateTime('2001/01/01'). >>> > (if you work with Gregorian Calendar of course). >>> > Behaviour must be the same in all possible implementations. >>> > >>> > However, in context of PSR-7, I see some cases when behaviour really >>> may differ. >>> > For example: >>> > > UriInterface::getAuthority() >>> > > If the port component is not set or is the standard port for the >>> current >>> > > scheme, it SHOULD NOT be included. >>> > >>> > It means that if I write >>> > echo $uri->withScheme('http')->withPort(80)->getAuthority(), PHP_EOL; >>> > it is possible to see different outputs: with port or without it. >>> > >>> > But the difference above is very minor. >>> > I doubt someone chooses a library just because it hides port or not. >>> >>> You'd be surprised. :-) >>> >>> > I also tried to find another good examples of different behaviour, but >>> I failed. >>> > >>> > — OK, what about existing libraries? Guzzle, HttpFoundation, etc. They >>> can attach our shiny interface to existing VOs, as simple as that. >>> > >>> > Sounds nice in theory, but in practice is not as simple. >>> > As far as I can see, most of popular libraries made new components to >>> work with PSR-7. >>> > For example: >>> > https://github.com/zendframework/zend-http/tree/master/src vs >>> https://github.com/zendframework/zend-diactoros >>> > https://github.com/guzzle/psr7 >>> > https://github.com/symfony/psr-http-message-bridge (uses >>> zend-diactoros, but anyway) >>> >>> This is not s valid comparison. Each of these projects predates psr-7, >>> and adding psr-7 support cannot be done without breaking backwards >>> compatibility. As such, they each have multiple supported versions, >>> targeting the different APIs, or offer a parallel project, or are doing a >>> stepped migration. You can't erase history, or force an upgrade overnight. >>> >>> > — PSR-FIG doesn't provide ready-to-use components anyway. We are not a >>> framework. >>> > >>> > From my point of view, it sounds like excuse for comment-driven >>> development. >>> > You did great work with specification. >>> > However, probably every statement from spec can be programmed very >>> unambiguously. >>> >>> The key word here is "probably". Considering we have multiple >>> implementations that do differ, and which are now generating errata due to >>> differences observed, I disagree with your assertion. >>> >>> -- >>> Matthew Weier O'Phinney >>> https://mwop.net >>> >> -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscr...@googlegroups.com. To post to this group, send email to php-fig@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/6828084d-bf76-4de9-a2a7-8fd588c3f948%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
