Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81325
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.173 as permitted sender)
Sender: Michael Wallner <mike.php.net@gmail.com>
Message-ID: <54C934C1.6080601@php.net>
Date: Wed, 28 Jan 2015 20:13:05 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Andrea Faulds <ajf@ajf.me>, Levi Morrison <levim@php.net>
CC: PHP Internals <internals@lists.php.net>
References: <54C8D36E.7010803@php.net> <CAFMT4NpjFSycCVrSUfBBgfJEJv=4Yw8cpmQ-45JWf=75ptr8Lg@mail.gmail.com> <CAFMT4NqUU21HGuOf1qZiHP8MvzG4q=o8G99UN5ushLZLh3ydtg@mail.gmail.com> <584E167F-CD06-4ACB-A33A-92DD178BCFD8@ajf.me>
In-Reply-To: <584E167F-CD06-4ACB-A33A-92DD178BCFD8@ajf.me>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] [VOTE] pecl_http
From: mike@php.net (Michael Wallner)

On 28/01/15 19:03, Andrea Faulds wrote:
> Hi Levi,
> 
>> On 28 Jan 2015, at 17:58, Levi Morrison <levim@php.net> wrote:
>> 
>> Oh, one more item: has anyone had time to review the pieces and how
>> they all interact, as well as reviewing the quality of each
>> component? I should hardly think in the time given this has been
>> done. I'm not saying this extension is bad; I am saying that I
>> don't think there's been time for anyone to properly evaluate
>> whether it is or not.
> 
> Related to that: I should have asked about the size. By the looks of
> things pecl/http is a pretty big extension that covers an awful lot
> of functionality. The RFC’s lack of rationale for adding the
> extension is bad enough, but the size of the extension makes it
> worse. It’s a lot of classes (28 in total), so I think the RFC really
> needs a strong case to add all these different modules. Not only does
> the RFC need an overall rationale, but each module probably needs its
> own rationale: how does it compare to PHP’s existing functions for
> that feature, etc.?

Yes, it's huge, but mostly only because PHP, the web language, lacks in
all of those areas. A quick overview of the top namespace:

- Client

The http stream wrapper is a hack and the existing libcurl binding is
subpar. They could be improved separately, but that is not subject of
this RFC.

Currently only libcurl is implemented as a provider for the client
functionality. Provides most of the functionality of current libcurl.
Representation of the request and response how a client sees them.
Support for parallel requests and optional libev{,ent} support.

- Cookie

Parses Cookie and Set-Cookie header values. Actually builds on http\Params.

- Encoding

Streamable implementations of chunked, zlib/gzip/deflate encodings.

- Env

Negotiation facilities, representations of the request and response how
the server sees them. Support for range requests and caching by
etag/last-modified.

- Header

Header parser and tools.

- Message

Message parser and tools. Also message bodies with support for building
and parsing multipart bodies.

- Params

Header params parser; think of a content-type or an accept header.

- QueryString

Query string parser and tools. Actually builds on http\Params.

- Url

URL parser and tools (actually discovered today, that it leans towards IRIs)



-- 
Regards,
Mike