Hi all, First, I want to reiterate that my initial desire was to submit this to PECL, to give the project some exercise before bringing it to internals. If someone here can nudge the PECL folks about my account request, that'd be appreciated. Otherwise, I'm happy to continue the discussion here.
Now, on to the questions and criticisms. * * * > On Sep 26, 2016, at 16:10, Korvin Szanto <korvinsza...@gmail.com> wrote: > > Personally I would prefer complete HTTP message objects similar to existing > PSR-7 implementations be added perhaps alongside these simple classes you've > proposed. Mike Wallner notes his pecl_http work, which I think is good for complete HTTP messages. * * * > On Sep 26, 2016, at 16:32, Rowan Collins <rowan.coll...@gmail.com> wrote: > > 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? The part that's hard to do in userland is public read-only properties that cannot be subverted by child classes. As to building it into core, I think it'd probably be better in PECL first, but my application there has been ignored so far (though maybe I've not waited long enough). > 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? I did use it as a research subject, but I failed to include it in my notes; I will add it. I was a sponsor on PSR-7, and I've worked with implementations since before the PSR was finalized. I put together the Relay middleware dispatcher, and some middleware pieces, and some applications, all using PSR-7, so I'm relatively familiar with its ins and outs. However, I have come to think of it as "not having lived up to its promise." That's not to denigrate MWOP, its lead author, whom I encouraged throughout the PSR process. But the PSR-7 claim of "immutability" turns out to be only partly true; instead, it is quasi-immutable, and so it has the problems that come with both mutability and immutability. There are some other problems, which if you press me on I'll go into, but not eagerly and only with trepidation. This work steps back a little bit, to survey the actual implementations of server-side requests and responses in userland, and bring together their similarities (with a very little bit of refinement), instead of building an entirely new and not-thoroughly-examined way of doing things. > Regarding the design of the objects themselves, why is stdRequest > property-only, but stdResponse method-only? The asymmetry feels awkward to me. Yeah, I get that. They use PHP itself as the example, where the superglobals carry all the request-related information, and global functions handle all the response-related activity. Part of the idea is to make using StdRequest and StdResponse "feel" a bit more like using the superglobals and global functions, while still corralling the related information into its own space inside an object. * * * > > On Sep 26, 2016, at 16:45, Michael Wallner <m...@php.net> wrote: > > Did you include pecl/http in your research? I did, but I failed to note it. I will do so. > It looks like it covers most of that already, if not all. > I know you said *not* HTTP messages per se, but I don’t see a lot of a > difference. One difference regarding StdRequest is that everything is exposed as read-only public properties. All of the frameworks/libraries I looked at had equivalents of this: $value = $request->getPost($key, $default_value); That's to provide a default value if a particular $_POST key is not available. However, under PHP 7, the ?? operator makes that kind of method unnecessary: $value = $request->post[$key] ?? $default_value; Further, StdRequest includes things that are not part of HTTP messages (e.g. all $_ENV values, and some $_SERVER values). The main difference regarding StdResponse is that instead of attempting to mimic an HTTP Message model, it mimics PHP functionality, except buffering the calls instead of sending them right away. (There are some added convenience methods as well, drawn from the research subjects.) * * * > On Sep 26, 2016, at 16:52, Davey Shafik <da...@php.net> wrote: > > 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've spoken with Davey, and the summary seems to be that server-push is possible, though in an impoverished way, via Link headers. Those can be added with header(), which means they can be added with StdResponse::setHeader(). As far as the rest, they are the subject of future work from Davey, which I look forward to, and will be happy to incorporate as it becomes available. (Davey, please correct me if I got that wrong.) > I'd rather look at this as the target for this kind of exploration and > implementation. To be clear, the StdRequest/StdResponse classes are not intended as exploration; they are "summaries" of existing work in the field. -- Paul M. Jones http://paul-m-jones.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
