Why would it be more work to do, for example, a URI abstraction first, as a separate PSR?
By my calculations, getting people to agree about smaller, isolated abstractions should be a lot easier than getting people to agree on a larger, combined package of abstractions. You had to do the same work regardless, write the same specifications, etc. Does the process itself really create that much overhead? I mean, I know it's a lot of work - I'm involved in the HTTP factory and HTTP middleware proposals right now, and it has been far more work than I had ever anticipated. Anyhow, the main reason I brought it up is, can we fix it? Or is it simply too late? Simply splitting the PSR and packages doesn't seem like an option, since unfortunately the package is namespaced as Psr\Http\Message, and URIs do not belong to the message sub-domain at all - likewise, Streams do not even belong to the HTTP sub-domain. One way to address this, maybe, would be to simply duplicate the interfaces, e.g. so that a class could implement both, say, Psr\Http\Message\StreamInterface and Psr\StreamInterface. The more correct solution would be a 2.0 release of PSR-7 that depends on two new PSRs. Client code would need to upgrade by replacing, for example, references to Psr\Http\Message\StreamInterface with Psr\StreamInterface, etc. But is there any kind of policy about PSR versioning? Is a 2.0 of an existing, approved PSR even a thing, or are they finite and set in stone forever? Or how does that work? On Sun, Sep 25, 2016 at 7:47 AM, Larry Garfield <[email protected]> wrote: > 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 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/cLfsPZQVTuA/unsubscribe. > To unsubscribe from this group and all its topics, 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. -- 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/CADqTB_i-ovk2cnrs6mqT%3DBwmJ4mfxdT%3DcZHc-J1_PhLtgXBM4g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
