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