Matthew said tat ZF3 will use PSR-7, does it mean ZF3 will be wrapping the output in a stream like that?
--
I started working on a PSR-7 implementation and I MessageInterface got me thinking about it being much more overhead than needed compared to a simple "echo". What I mean is that after you have your response generated wrapping that string into a stream seems a bit of redundant. Especially considering that to provide methods like tell() and the like instead of "echo"-ing the stream would pretty much have to use output buffering which is sort of an overhead.
These are nice and they do mention wrapping the php://output stream. But that really doesn't address the issue of having to handle things like headers, cookies and the like without the use of the already proven standard PHP functions instead of rolling out my own buggy ones. Event hat is not a huge deal since I'm sure in the end we'll have a very elegant and correct implementation done by someone. But I'd really like to benchmark that implementation when it comes out.This is not an issue with a PSR itself, it's just that I feel that a feature that is definitely used all the time ( request/response handling being such ) should be as efficient as possible. And the standard functions have been awesome so far.
Well yes, but React is hardly a generic use case. Im more concerned about "regular" apps.
--
You received this message because you are subscribed to a topic in the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/php-fig/zzmpUsZoarQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CADyq6sKfCSd2uqXEMUws-eUJypm6x%2BW95Z8SQnJj42CUxJRzhw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Well I'm not just talking about writing speed, that I think actually shouldn't change much. I'm more concerned about handling the protocol without the use of good old functions like setcookie
--
You received this message because you are subscribed to a topic in the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/php-fig/zzmpUsZoarQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAJp_myX6uOdAH8%2BMBDuHwM1Z8vFE7g2J5G%2BoLK__2Mg-9y2UxQ%40mail.gmail.com.
Well yes, but the standard functions like set_header() dont work with streams, so it wont be possible to use them to create a native-ish representation. The only way I see of fixing this is dropping streams from the PSR. Since actually having streams does already restrict you to a particular implementation.
Perhaps a nice idea would be to have interfaces that just do getting and setting of headers and such. The messages would probably still have to be some sort of a stream, but maybe with much more limited interface ( just read/write instead of tell ) and the having a separate interface for a ResponseWriter that would do the whole stream thing.
This way a Response represented by such an interface could be printed by a NativeResponseWriter that utilizee native fubctions
You received this message because you are subscribed to a topic in the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/php-fig/zzmpUsZoarQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAJp_myW2UcOc2dhX4pHvgBNp3x7oN2TxJ71-B12j%3DpMwN-PDEg%40mail.gmail.com.
--
You received this message because you are subscribed to a topic in the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/php-fig/zzmpUsZoarQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to php-fig+unsubscribe@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/55122BCA.2020004%40garfieldtech.com.
The problem is that it looks like with PSR-7 I have to use an output stream wrapping around php://output . And if I do that I can't use the header9) method and setcookie
To unsubscribe from this group and all its topics, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
And if I do that I can't use the header9) method and setcookie
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/39773cdb-d232-42ec-99cb-8493ec5de118%40googlegroups.com.
Some of them will use header() and setcookie()
--
You received this message because you are subscribed to a topic in the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/php-fig/zzmpUsZoarQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to php-fig+unsubscribe@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/5512D6CE.40207%40garfieldtech.com.
Some of them will use header() and setcookie()
I mean what is the point of having a generic HTTP interface intended for interpolability if a huge part of how it's used (cookies) remains unstandardized and will have to rely on each indivdual representation.
--
You received this message because you are subscribed to a topic in the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/php-fig/zzmpUsZoarQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/ee3106c9-a3bd-4345-bb2a-2e92913fd17f%40googlegroups.com.
To unsubscribe from this group and all its topics, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
When it comes down to it, cookies are are just headers.
Well that would still be a problem:
Setting the same cookie multiple times would result in multiple set-cookie headers. And again you would rely on parsing cookie into heqder yourself instead of using setcookie
You received this message because you are subscribed to a topic in the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/php-fig/zzmpUsZoarQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAJp_myW94KSTgiXkv0g6LXsNx0k_1BWr4UuH-P2%2BxHNvfr2DLA%40mail.gmail.com.