Hi Daniel! > On 30 01 2015, at 07:28, Daniel Lowrey <rdlow...@php.net> wrote: > > 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!
Thank you for taking the time to make your opinion public on internals, I appreciate. PHP should definitely take care to provide a reasonable API, but there’ll never be satisfaction for everyone. I think PHP is, and should be, a language where you’re more successful in getting things done, instead of having to do it right in one way only. This is not the end of the world for other HTTP components, see mysql/mysqli/PDO for example, but in my opinion it is the best we can do now for HTTP in PHP. Thank you, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
