On 28/01/15 19:03, Andrea Faulds wrote:
> Hi Levi,
> 
>> On 28 Jan 2015, at 17:58, Levi Morrison <le...@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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to