On Saturday, September 24, 2016 at 7:29:55 AM UTC-6, Rasmus Schultz wrote: > > Hey FIG, > > This week, I found myself doing some work with native PHP stream > resources. This particular work had no relation to HTTP at all, but to SMTP > as it happens. While writing this project, I thought, I should abstract > streams behind an interface. Of course, then it occurred to me, PSR-7 > includes a stream-abstraction. However, PSR-7 is primarily for HTTP > Messages - it seemed wrong to depend on an HTTP abstraction just for the > stream-abstraction, so I ended up not doing that. In the end, I went with > plain PHP stream resources, for two reasons - primarily because I didn't > want to depend on an HTTP abstraction for streams, and also because the > stream-abstraction of PSR-7 doesn't cover stream-filters, which I needed > for this project. > > Which brings me to my question: why was the stream-abstraction rolled in > with the HTTP abstraction? (I did not find this question/answer in the > PSR-7 meta.) It seems like a stream-abstraction is a completely general > thing - it's not specific to HTTP concerns at all; PHP streams are used for > plenty of other things, and this abstraction could perfectly well stand > alone without the HTTP abstraction, or not? A stream-abstraction seems like > it's more naturally a dependency of an HTTP abstraction - rather than > belonging to it. Is there a rational reason why two seemingly unrelated > abstractions were put into a single PSR? >
My guess (I wasn't involved in the process on this one) is that the stream abstraction was considered useful, and no other PSR was already covering it at the time. While splitting that into its own PSR makes sense, the added complexities of developing a second PSR, especially when the current one relies on its content, would likely have been seen as an unnecessary complication for the current PSR itself - that is, PSR-7 would likely still be unapproved, waiting on the Streams PSR to be finalized, first, along with all the unforeseen complications it would have along the way. Ultimately the right approach? Hard to say, but looking back provides a much different view than looking forward. > How would you feel about having a separate PSR for streams? And possibly > extending the scope to also include a stream-filter abstraction? > For my part, a full-blown Streams PSR makes sense. Especially if it can be made to expand the stream interface in PSR-7, such that compatible implementations could be used there as well. Not necessarily *extending* it, per se, though I suppose that would probably also be a good idea for continued compatibility between the PSRs. Especially since PSRs can't really be revised once approved. Of course, I'm not a voting member, so this is just my 2ยข... > Thanks, > Rasmus > - Dan -- 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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/f0816a30-2bcf-4b7c-8e04-91d430966206%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
