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