Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81405
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.169 as permitted sender)
Sender: Michael Wallner <mike.php.net@gmail.com>
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
In-Reply-To: <CAH8MpnnLnUgbgWM0o8MO8=a0bP==cbLapXmpTmEqO2iZYSS1gQ@mail.gmail.com>
Date: Fri, 30 Jan 2015 08:10:21 +0100
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <BD568277-5A74-4A66-AC5D-173DA93FA8FB@php.net>
References: <CAH8MpnnLnUgbgWM0o8MO8=a0bP==cbLapXmpTmEqO2iZYSS1gQ@mail.gmail.com>
To: Daniel Lowrey <rdlowrey@php.net>
Subject: Re: [PHP-DEV] [RFC] [DISCUSSION] pecl_http
From: mike@php.net (Michael Wallner)

Hi Daniel!

> On 30 01 2015, at 07:28, Daniel Lowrey <rdlowrey@php.net> wrote:
>=20
> Hi Mike :)
>=20
> I'd like to chime in on the discussion ...
>=20
>=20
> 1. There is a lot of *really* useful functionality in pecl/http that =
IMO
> should be bundled with the standard PHP distribution.
>=20
> 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.
>=20
> 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.
>=20
>=20
> 2. There is some functionality here that isn't HTTP-specific and =
should
> exist in other extensions.
>=20
> 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.
>=20
>=20
> 3. There is some functionality here that IMO belongs in pecl/ and not =
ext/
>=20
> 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.
>=20
> 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.
>=20
>=20
> 4. There is some functionality here that will likely upset some people
> because it's subjective
>=20
> 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.
>=20
> ...
>=20
> So, in summary:
>=20
> 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.
>=20
>=20
> 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=E2=80=99ll never be satisfaction for everyone.

I think PHP is, and should be, a language where you=E2=80=99re 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
=20