Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81403
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.172 as permitted sender)
MIME-Version: 1.0
Sender: rdlowrey@gmail.com
Date: Fri, 30 Jan 2015 01:28:11 -0500
Message-ID: <CAH8MpnnLnUgbgWM0o8MO8=a0bP==cbLapXmpTmEqO2iZYSS1gQ@mail.gmail.com>
To: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=047d7bdc143874bfa0050dd8b594
Subject: Re: [RFC] [DISCUSSION] pecl_http
From: rdlowrey@php.net (Daniel Lowrey)

--047d7bdc143874bfa0050dd8b594
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Jan 29, 2015 at 8:14 PM, Michael Wallner <mike@php.net> wrote:

> I=E2=80=99ve 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 th=
e
> 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

--047d7bdc143874bfa0050dd8b594--