On 09/24/2016 11:17 PM, Daniel Hunsaker wrote:
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.
From what I recall, that is a fairly accurate summary. The same
applies to UriInterface, which is technically useful outside of HTTP
messages but trying to factor that out was just more work than anyone
had the stomach for.
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ยข...
I would much rather see PHP's native stream interfaces improved to not
suck, rendering a user-space wrapper of them unnecessary. If wishes
were horses... :-)
--Larry Garfield
--
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/fd07b8eb-4194-fa4f-9a89-f71bf54aa520%40garfieldtech.com.
For more options, visit https://groups.google.com/d/optout.
