Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81344
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.27 cause and error)
Message-ID: <54C95529.6040907@garfieldtech.com>
Date: Wed, 28 Jan 2015 15:31:21 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <54C8D36E.7010803@php.net> <54C9338A.7020202@beccati.com> <54C9363D.6090102@php.net> <54C94A9D.8000904@beccati.com>
In-Reply-To: <54C94A9D.8000904@beccati.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] [VOTE] pecl_http
From: larry@garfieldtech.com (Larry Garfield)

On 1/28/15 2:46 PM, Matteo Beccati wrote:
> On 28/01/2015 20:19, Michael Wallner wrote:
>> On 28/01/15 20:07, Matteo Beccati wrote:
>>> As Nikita mentions, PSR-7 is under way and currently gaining some
>>> traction. At the moment the PSR-7 interfaces are designed to be
>>> immutable, although I that's still open for debate. If the RFC passes,
>>> we'd be taking a fairly strong position and pushing the current
>>> pecl_http implementation as a de-facto standard. Sure, PHP-FIG would
>>> still be free to come up with their own standard, but it just doesn't
>>> seem much fair to me.
>>
>> Why is everybody so obssessed by the word "standard"?
>> What is "fair" supposed to mean in this regard?
>  >
>> Doesn't FIG stand for Framework Interoperability Group? I've been there
>> and wanted to start a discussion on the topic, but without success.
>
> Seen that too. Welcoming "BE GONE FOUL INTERNALS DEVELOPER" joke aside,
> some objections have been made. You didn't like them, you disappeared
> suggesting PHP-FIG to "play alone in your shady little shed".
>
> Since PSR-7 is being discussed now *and* pecl_http can't implement an
> interface that still is being discussed, I would rather vote "no" now
> and maybe change my mind in future if PSR-7 becomes a thing and
> pecl_http follows. Or PSR-7 fails, for that matter.

I actually quite like the idea of PHP core having HTTP message objects 
built in, and a good HTTP client built in.  These are both good things.

However, from the docs and the minimal RFC I really cannot say if 
pecl_http is a good candidate for that.  The current state-of-the-art 
for those in the userspace world are PSR-7 (draft), and Guzzle (client), 
which have been informing each other as they develop.  It doesn't appear 
on the surface as though the current RFC has been informed by those 
processes.

I would much rather let that play out, and userspace verify that the 
PSR-7 model (whatever it is) is what we actually want.  Assuming it is, 
or it would be with some tweak that we only find out once it's in 
widespread use, we can move a nearly-identical model (or a 
smartly-selected subset of it) into C code and benefit everyone.  That's 
something FIG and Internals can and should do collaboratively.

However, merging pecl_http now would effectively result in PHP releasing 
two different, incompatible standards for HTTP handling in the same 
year.  That seems counter-productive. :-)

I don't have an Internals vote, but if I did I would be voting no at 
this time.  I'd rather revisit this in a year or two, in a 
userspace/internals collaborative manner.

--Larry Garfield