On Thu, Jan 29, 2015 at 8:14 PM, Michael Wallner <m...@php.net> wrote:
> I’ve rewritten the RFC for pecl_http and hopefully addressed most of the > things mentioned previously. > > I you still find anything lacking, please let me know, so I can expand the > RFC accordingly. > > And of course, everything else is up for discussion. > Hi Mike :) I'd like to chime in on the discussion ... 1. There is a lot of *really* useful functionality in pecl/http that IMO should be bundled with the standard PHP distribution. This, to me, means things like parsing functionality that is conspicuously absent in a web-first language like PHP. HTTP messages, cookies, header parameters, multipart/form-data ... these are all standard HTTP elements for which we have no compiled parsing capabilities in the standard distribution. Adding this functionality in ext/http would be an instant win for my own work and I'm sure for many others as well. Moreover, parsing is the type of functionality that *really* benefits from being compiled as compared to happening in userland. Finally, this type of functionality is pretty vanilla and straightforward -- there is little room for stylistic disagreements in APIs and implementations. No one is going to complain that a multipart/form-data parser API is "zomg so bad I need to tweet my frustration about #php right now." If it parses data how it's supposed to it's generally good enough. These are the kinds of things that ought to be bundled with the standard PHP distribution. They'd be a win for everyone and shouldn't realistically upset or confuse anyone. 2. There is some functionality here that isn't HTTP-specific and should exist in other extensions. I'm talking specifically here about the Encoding\Stream things. In fact, I had planned to PR essentially the same thing for ext/zlib between now and the 7 feature freeze. This is functionality that isn't specific to HTTP and belongs in ext/zlib, especially considering it relies on the zlib dependencies in the first place. I don't think it's a good idea to do this. It's missing functionality in another extension -- it should be PR'd and included there. PHP is well-known for its perceived "lack of direction" and this kind of overlap is exactly what people point to when they denigrate the language. If we already have these extensions lets update them instead of adding more extensions to cover holes in the existing ones. I'd personally prefer to see new development/inclusions take the wide view of the distribution as one whole PHP and not an incoherent mish-mash of overlapping extensions. 3. There is some functionality here that IMO belongs in pecl/ and not ext/ There are a lot of "extras" here. PHP's existing HTTP functionality is already spread all over the map and bundling this additional functionality certainly won't help to mitigate that. This ties in somewhat with my previous point, but ... we have superglobals, ext/curl, file_get_contents(), etc. Do we really need to bundle another extension that depends on curl to make HTTP requests? Do we really need to bring in two other pecl libs as hard dependencies for this? I don't really see enough benefit here to muddy the waters in such a way. Beyond this, http requests are IO-bound transactions ... this is something that can be done quite well (and is already) with existing userland libraries without incurring significant performance degradation. I don't see the need for all this extra stuff to add functionality that we already have. 4. There is some functionality here that will likely upset some people because it's subjective I'm speaking specifically about type abstractions like Message (and friends). This is functionality that provides very little performance benefit from being compiled and causes all sorts of disagreement and bikeshedding over API details. Obviously there's the whole PSR-7 thing happening right now which will be subjugated to any bundled HTTP abstractions in the standard distribution. While I personally have a lot of real problems with the API the FIG people are pushing, we certainly won't be making friends by adding a de facto "standard" HTTP API to the language with which they disagree. These are APIs which should be carefully considered at a community level in a web-first language. Short of that kind of consensus, I don't see how it's a good idea to bundle that kind of API with the rest of the language. ... So, in summary: If I had to take all of pecl/http or none of pecl/http right now ... I would vote, "no," because while I want (and need) the capabilities from #1, I believe the associated drawbacks are too extensive to bring all the extra baggage into the standard PHP distribution. Thanks to anyone who read this phonebook of a mail all the way to the bottom! -Daniel
