On Mon, Sep 26, 2016 at 2:32 PM, Rowan Collins <rowan.coll...@gmail.com> wrote:
> On 26/09/2016 20:37, Paul Jones wrote: > >> tl;dr: Gauging interest in an extension for server-side PHP request and >> response objects (*not* HTTP messages per se; see below) prior to writing >> an RFC for them on the wiki. >> > > This sounds like an interesting project, but I have a few questions. > > First, the obvious one: why does this need to be an extension and/or built > into core? Are there reasons such as performance for implementing this in C > rather than PHP? Does it provide functionality that is hard to implement in > a userland library? > > You mention that it is not just an HTTP wrapper, but although you mention > researching other frameworks, I can't see any reference to PSR-7 [ > http://www.php-fig.org/psr/psr-7/]. What do you see as the relationship > between your proposal and that standardisation effort? > > Regarding the design of the objects themselves, why is stdRequest > property-only, but stdResponse method-only? The asymmetry feels awkward to > me. > > I think the most interesting parts are those that attempt to rationalise > $_SERVER, and I think a library (or built-in functionality) devoted to > those could be very useful. Some of that overlaps with PSR-7, but that > standard doesn't go into depth on things like Accept headers, > Authentication, etc. > > Like I say, it's an interesting idea, but I'm not sure how it fits in with > the wider ecosystem. Additionally to this, we need to start thinking about what it means to move away from simple request/response architectures. In the age of WebSockets and HTTP/2 multiplexing w/Server Push, the likelihood of multiple responses for one request, or even responses with no associated request, are possible. I'd rather look at this as the target for this kind of exploration and implementation. - Davey
