Re: New Standardized HTTP Interface

On 10/31/14, 12:38 PM, Sherif Ramadan wrote:

On Fri, Oct 31, 2014 at 1:32 PM, Florian Margaine <florian@margaine.com> wrote:

Hi, Le 31 oct. 2014 18:28, "Sherif Ramadan" <theanomaly.is@gmail.com> a écrit :

On Fri, Oct 31, 2014 at 1:09 PM, Rowan Collins <rowan.collins@gmail.com> wrote:

Let me repeat my question: Say I write a class "AwesomeHTTPReceive implements HttpMessageReceive", what do I then do with this class in order for it to perform any

actions?

How does PHP know that my class is the one it should populate, or when that population should happen?

It wouldn't. You would need to extend the base class, since it already implements the necessary interface. PHP would simply call on the last subtype of HttpRequest during the request init phase.

What if there is multiple subtypes? class A extends HttpRequest {} class B extends HttpRequest {} What happens there?

As of now, all the subtypes would be called, i.e. if A has a receiveMessage method, it would be handed the message, and if B has a receiveMessage method it too would be handed the message. It's up to those methods to call on subsequent parsing methods to do something with the message, obviously any methods they don't implement are forwarded to the parent. This clearly has some conflicts, like if default parsing is left we overwrite superglobal variables. However, it also has benefits, in that we can have multiple implementations for handling the request in the same code base and it is left up to the user to decide which one to use. So, again, this is still a draft and I'm open to suggestions about how to handle/deal with such problems.

I think the root problem is that you're solving an issue that doesn't exist. You're talking about providing alternate ways to parse the raw HTTP stream into user-accessible variables, ie, by pushing them into an object of a known interface rather than/in addition to the superglobals. In my 15 years of writing PHP I have never wanted to change the way the raw HTTP is parsed. I have, however, frequently wanted to have the data accessible in a more logical, semantic, and HTTP-correct way. ($_GET is not about HTTP GET, it's about URI query parameters. $_POST isn't about HTTP POST, it's about application/x-www-form-encoded. Etc.) And I've wanted that information available in a non-global, OOP-injectable way. But I've never once had any desire to change the way an application/x-www-form-encoded is parsed. Implementation problems aside, your proposal is not solving an extant problem. If we want to improve PHP's HTTP handling, then having an object that exposes the HTTP request in a more logical fashion would be far more useful, and/or providing that data in a more logical way so that someone in user-space can provide that data in a logical fashion (eg, via a PSR-7-implementing object.) I already stated in an earlier email what I felt would be most beneficial for internals to do toward that goal (specifically, clean up the streams API so that we can use it directly from an OOP world rather than a 1980s C world.) IF internals wanted to add implementation, not just improving streams, something like the following would be much more useful: $request = http_get_request(PHP_STDIN); // or something Where $request is an object that implements the PSR-7 RequestInterface (or at least the read-only parts of it), or something similar. Then implementers can compose that object however they want. Although at least for the near term I think it's better to not do that and just do the lower-level plumbing to make FIG's work with PSR-7 easier. --Larry Garfield