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? How would you feel about having a separate PSR for streams? And possibly extending the scope to also include a stream-filter abstraction? Thanks, Rasmus -- 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/01980890-9b51-429d-afc4-39386ceb198c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
