Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81384
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: <54CA77CC.8040105@garfieldtech.com>
Date: Thu, 29 Jan 2015 12:11:24 -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: <DDA98D4F-2105-415A-B921-01A622091FA9@php.net> <E58D2EFD-4531-4A1F-B71A-D847C4D2EBA6@ajf.me> <54CA2512.5040807@googlemail.com> <5FAD6FD2-FAEB-4494-B4FB-71A47AC7760A@ajf.me>
In-Reply-To: <5FAD6FD2-FAEB-4494-B4FB-71A47AC7760A@ajf.me>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] [DISCUSSION] pecl_http
From: larry@garfieldtech.com (Larry Garfield)

On 1/29/15 6:40 AM, Andrea Faulds wrote:
>
>> On 29 Jan 2015, at 12:18, Crypto Compress <cryptocompress@googlemail.com> wrote:
>>
>>
>>> * Why should we have our own HTTP API and not follow PSR-7?
>>
>> possible points:
>> - PHP-FIG propose no implementations; pecl_http does
>> - native implementations should be faster
>
> I don’t see how that’s relevant: I’m talking here about the API, not the implementation. Why should PHP’s HTTP API not be PSR-7?
>
>> - PHP-FIG focus on frameworks; pecl_http in core is useable without dependencies by every simple script
>
> Also irrelevant, there’s no reason it couldn’t use PSR-7’s API.
>
>> - PSR-7 is a moving target; pecl_http exists for ten years
>
> Fair point.
>
>> - PSR-7 can be complementary to pecl_http not the other way around (c code can't use php code?)
>
> Not necessarily true.
> --
> Andrea Faulds
> http://ajf.me/

In my rainbows and ponies vision of the future, it would go something 
like this:

1) PSR-7 is approved.  People use it.  People love it.

2) Internals makes internal definitions of the interfaces from PSR-7, 
renamed to a PHP namespace but otherwise identical.  Eg:

\Php\Http\Message
\Php\Http\Request
\Php\Http\Response
\Php\Http\ServerRequest

FIG makes available an alternate set of interfaces that are PSR-7 but 
extent the internal ones for type hint compatibility.

Someone (FIG, internals, me?) makes a user-space definition of the new 
internals interfaces as a BC layer.

3) Internals improves its userspace stream APIs such that the 
StreamInterface from PSR-7 can be retired completely.  (It exists almost 
entirely as a way to avoid dealing with the PHP-native stream APIs.)

4) Internals adds a function/routine/thing to spawn a ServerRequest that 
is equivalent to the user-space code to create a PSR-7 ServerRequest out 
of the superglobals.  It is, of course, faster than doing in userspace 
and also more standard.  Internals also adds a "send this response 
object to this stream (default stdout)" routine.

5) Everyone switches over to using the Internals-named interfaces and 
ServerRequest builder. Because the interface is the same aside from the 
name this is about a 5 minute task per project and could be done by a 
small shell script.

6) Internals build a simple HTTP client that uses \Php\Http directly. 
It's probably not as powerful as Guzzle et al but easily extensible. 
Because user-space clients are already using those interfaces, that 
makes swapping the new Internals one in instead is a really easy task. 
Guzzle et al can convert to being extensions on the core one, all using 
the common interfaces.

7) The Ewoks, they dance!

I don't expect it will happen exactly like that, of course, but the 
closer we can get to that sort of chain of events the better I think it 
will be for everyone.

Note that the interface definition parts are separate from the writing 
of the HTTP client.  I think it's important to address those two 
separately.  SRP applies to RFCs just as much as code. :-)

--Larry Garfield