Re: [PHP-DEV] [RFC] [DISCUSSION] pecl_http
On Wed, Feb 11, 2015 at 5:16 PM, Michael Wallner m...@php.net wrote: On 06/02/15 17:44, Daniel Lowrey wrote: If you doubt that this is a solved problem in userland consider the performance of my own 100% userland HTTP client demonstrated here without the use of curl or any other extensions: https://gist.github.com/rdlowrey/54171625334670ccb9f5 I can replicate about 2.5s with artax/master on http://example.org, which is about the same pace like pecl_http. With pipelining enabled pecl_http/master peeks at about 0.7s, but what's the point? PS: I'm on an advertised 150/15 Mbit connection. -- Regards, Mike The point isn't *zomg this one thing I did in userland is super fast.* It's irrelevant. The point here is that HTTP transfers are an IO-bound operation and as such the benefit from compiling them is relatively small. Add that to the fact that we already have tools to do exactly this in the standard distribution (curl) and well-known, well-tested userland tools for any use-case you can imagine. In my opinion that adds up to not needing another way to do the same thing in the standard distribution. Who benefits from bundling another HTTP client? Why bring in two additional pecl dependencies for HTTP connections which *rarely* make sense to persist across web SAPI requests? Is there a plan to also deprecate ext/curl? These are questions that aren't resolved in a satisfactory way as far as I'm concerned. I honestly don't care that much, I just don't think because we can necessarily means we should when there's no obvious need for more of the same overlapping functionality. That's what pecl is for, right?
Re: [PHP-DEV] [RFC] [DISCUSSION] pecl_http
On 06/02/15 17:44, Daniel Lowrey wrote: If you doubt that this is a solved problem in userland consider the performance of my own 100% userland HTTP client demonstrated here without the use of curl or any other extensions: https://gist.github.com/rdlowrey/54171625334670ccb9f5 I can replicate about 2.5s with artax/master on http://example.org, which is about the same pace like pecl_http. With pipelining enabled pecl_http/master peeks at about 0.7s, but what's the point? PS: I'm on an advertised 150/15 Mbit connection. -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [DISCUSSION] pecl_http
On 06/02/15 17:44, Daniel Lowrey wrote: I’ve rewritten the RFC for pecl_http and hopefully addressed most of the things mentioned previously. I you still find anything lacking, please let me know, so I can expand the RFC accordingly. And of course, everything else is up for discussion. I may not have been clear before, but just to be sure ... I would really like to see the pecl/http RFC broken up into multiple voting options instead of one giant yes or no as per my previously mentioned concerns: 1. There is a lot of *really* useful functionality in pecl/http that IMO should be bundled with the standard PHP distribution. 2. There is some functionality here that isn't HTTP-specific and should exist in other extensions. 3. There is some functionality here that IMO belongs in pecl/ and not ext/ 4. There is some functionality here that will likely upset some people because it's subjective I also want to reiterate my feeling that PHP *does not* need to bundle yet another HTTP client -- especially one that brings other pecl dependencies with it. There's just no reason for doing this (other than API waffling). Performance is not a valid reason (we have ext/curl, which is fine if you want something that's compiled). Also, when you consider that HTTP resource traversal is more than adequately handled in userland already this addition just doesn't make a ton of sense to me. Let's bring the things that actually benefit from being compiled into the standard distribution; the rest should stay in pecl. If you doubt that this is a solved problem in userland consider the performance of my own 100% userland HTTP client demonstrated here without the use of curl or any other extensions: https://gist.github.com/rdlowrey/54171625334670ccb9f5 If this proposal is all or nothing then I have to vote no ... and it would be a shame to miss out on the beneficial portions of pecl/http :( While I think it's not a particularly good reason to vote no, it may very well be a valid one; but I'm not conviced that splitting it up makes the situation any better. I really don't want to compete with the client you've written, but it seems this is the only thing you oppose to? -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [DISCUSSION] pecl_http
I’ve rewritten the RFC for pecl_http and hopefully addressed most of the things mentioned previously. I you still find anything lacking, please let me know, so I can expand the RFC accordingly. And of course, everything else is up for discussion. I may not have been clear before, but just to be sure ... I would really like to see the pecl/http RFC broken up into multiple voting options instead of one giant yes or no as per my previously mentioned concerns: 1. There is a lot of *really* useful functionality in pecl/http that IMO should be bundled with the standard PHP distribution. 2. There is some functionality here that isn't HTTP-specific and should exist in other extensions. 3. There is some functionality here that IMO belongs in pecl/ and not ext/ 4. There is some functionality here that will likely upset some people because it's subjective I also want to reiterate my feeling that PHP *does not* need to bundle yet another HTTP client -- especially one that brings other pecl dependencies with it. There's just no reason for doing this (other than API waffling). Performance is not a valid reason (we have ext/curl, which is fine if you want something that's compiled). Also, when you consider that HTTP resource traversal is more than adequately handled in userland already this addition just doesn't make a ton of sense to me. Let's bring the things that actually benefit from being compiled into the standard distribution; the rest should stay in pecl. If you doubt that this is a solved problem in userland consider the performance of my own 100% userland HTTP client demonstrated here without the use of curl or any other extensions: https://gist.github.com/rdlowrey/54171625334670ccb9f5 If this proposal is all or nothing then I have to vote no ... and it would be a shame to miss out on the beneficial portions of pecl/http :(
Re: [PHP-DEV] [RFC] [DISCUSSION] pecl_http
Hi Stas! On 30/01/15 20:10, Stanislav Malyshev wrote: Hi! I’ve rewritten the RFC for pecl_http and hopefully addressed most of the things mentioned previously. Thank you, Michael, this is much better! I would still like to hear more about 2 extensions, especially about raphf - it seems to be some framework for handling persistent resources, but it's not clear why we need persistent resources for HTTP module at all (who keeps HTTP connections open between requests?) and the code in the example doesn't show any significant logic there - it just basically wraps curl functions, so I wonder why we need whole new API in core for that? API consumers jump into mind f.e. libcurl caches connections itself, so, we're just re-using functionality from curl... with lots of good extras, like cached DNS entries, maybe TLS sessions etc. I also use it in pecl/pq a PostgreSQL client, which seems a perfect fit to me, i.e. any database extension not exposing its database handle as a userland resource should use raphf over zend_list IMO. But Dmitry or any other expert might of course want to say a few better words about zend_list. raphf comes with what's needed to maintain (persistent) service handles within objects. As already explained, we don't need extra refcounting because the objects are already refcounted, but we could need support for handle copy ctors to easily support object cloning, still manually, but without mind boggling code. The benefit of retire and wakeup handlers are already shown in the RFC, additionally, check out the resource factory ops of pecl/pq here: https://github.com/php/pecl-database-pq/blob/master/src/php_pqconn.c#L520-L561 Nothing super-complicated either; though, a copy constructor is not implemented, but that might only be a matter of creating a new connection with information out of PQconninfo(). I guess the brave one could implement similar stuff for zend_list, but all this zend_resource business is useless for interal handles. About propro - it says that it improves by-reference access to handler properties, which may be useful but I don't really see how it relates to HTTP module either - why would you need by-ref access in this context? Could you give any example of a common code pattern that was impossible without it but is enabled with it? It doesn't improve it, it yet makes it possible. It's an aid for internal classes that expose properties to userland that actually represent state stored in foreign C struct members, and not in the zvals in the properties table. Hope that sounds sane in any way?! -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [DISCUSSION] pecl_http
Hi! I’ve rewritten the RFC for pecl_http and hopefully addressed most of the things mentioned previously. Thank you, Michael, this is much better! I would still like to hear more about 2 extensions, especially about raphf - it seems to be some framework for handling persistent resources, but it's not clear why we need persistent resources for HTTP module at all (who keeps HTTP connections open between requests?) and the code in the example doesn't show any significant logic there - it just basically wraps curl functions, so I wonder why we need whole new API in core for that? About propro - it says that it improves by-reference access to handler properties, which may be useful but I don't really see how it relates to HTTP module either - why would you need by-ref access in this context? Could you give any example of a common code pattern that was impossible without it but is enabled with it? -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [DISCUSSION] pecl_http
Michael Wallner wrote in message news:bd568277-5a74-4a66-ac5d-173da93fa...@php.net... snip I think PHP is, and should be, a language where you’re more successful in getting things done, instead of having to do it right in one way only. Well said! I couldn't agree more. -- Tony Marston -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [DISCUSSION] pecl_http
Hi Mike, Awesome work! On Thu, Jan 29, 2015 at 8:14 PM, Michael Wallner m...@php.net wrote: I’ve rewritten the RFC for pecl_http and hopefully addressed most of the things mentioned previously. I you still find anything lacking, please let me know, so I can expand the RFC accordingly. And of course, everything else is up for discussion. https://wiki.php.net/rfc/pecl_http The URL is this, right? -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] [RFC] [DISCUSSION] pecl_http
Hi Mike, On 29 Jan 2015, at 11:14, Michael Wallner m...@php.net wrote: I’ve rewritten the RFC for pecl_http and hopefully addressed most of the things mentioned previously. I you still find anything lacking, please let me know, so I can expand the RFC accordingly. The RFC is an improvement in that it covers more of *what* pecl/http is, but it still doesn’t answer the most important question: why? It still doesn’t answer any of the following key questions: * Why do we need pecl/http? * Why should pecl/http be merged into PHP core? * Why should pecl/http be enabled by default? * Why should we have our own HTTP API and not follow PSR-7? * What does it offer over PHP’s existing HTTP capabilities? * Why should we merge this rather than, say, filling in gaps in PHP’s HTTP capabilities? So, I think the RFC is still rather lacking. The Features section isn’t really any better than before, either. It only gives a sentence or two to each module, which isn’t terribly informative. Each module probably needs its own rationale, and a comparison to PHP’s existing facilities, as well. Thanks. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] [DISCUSSION] pecl_http
Hi! I’ve rewritten the RFC for pecl_http and hopefully addressed most of the things mentioned previously. I you still find anything lacking, please let me know, so I can expand the RFC accordingly. And of course, everything else is up for discussion. Thanks, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [DISCUSSION] pecl_http
On 29/01/15 12:32, Yasuo Ohgaki wrote: Hi Mike, Awesome work! On Thu, Jan 29, 2015 at 8:14 PM, Michael Wallner m...@php.net mailto:m...@php.net wrote: I’ve rewritten the RFC for pecl_http and hopefully addressed most of the things mentioned previously. I you still find anything lacking, please let me know, so I can expand the RFC accordingly. And of course, everything else is up for discussion. https://wiki.php.net/rfc/pecl_http The URL is this, right? Yes, of course! Bad mistake, sorry. -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [DISCUSSION] pecl_http
* Why should we have our own HTTP API and not follow PSR-7? possible points: - PHP-FIG propose no implementations; pecl_http does - PHP-FIG focus on frameworks; pecl_http in core is useable without dependencies by every simple script - PSR-7 is a moving target; pecl_http exists for ten years - PSR-7 can be complementary to pecl_http not the other way around (c code can't use php code?) - native implementations should be faster -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [DISCUSSION] pecl_http
On 29 Jan 2015, at 12:18, Crypto Compress cryptocompr...@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/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [DISCUSSION] pecl_http
On 29/01/15 11:40, Andrea Faulds wrote: * Why do we need pecl/http? * Why should pecl/http be merged into PHP core? * Why should pecl/http be enabled by default? * Why should we have our own HTTP API and not follow PSR-7? * What does it offer over PHP’s existing HTTP capabilities? * Why should we merge this rather than, say, filling in gaps in PHP’s HTTP capabilities? On one hand third party packages are being pushed in place of the existing built in functions. Here a new set of built in functions are being proposed. Having used Apache for many years and now moved to Nginx as my 'interface', just where does this fit into the overall jigsaw. Using Nginx to handle the static stuff and only passing dynamic calls to php_fpm, just what http functionality is needed? The main reason for asking this question actually relates to implementing a server for tzdist which I can easily handle with the Nginx/php_fpm framework, and that should serve static pages until a change of version requires building a new data set. Is this the sort of process that can be handled totally within PHP and does that actually make sense where a large volume of static data is cached? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [DISCUSSION] pecl_http
On 1/29/15 6:40 AM, Andrea Faulds wrote: On 29 Jan 2015, at 12:18, Crypto Compress cryptocompr...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [DISCUSSION] pecl_http
Hi all, On Thu, Jan 29, 2015 at 9:18 PM, Crypto Compress cryptocompr...@googlemail.com wrote: possible points: - PHP-FIG propose no implementations; pecl_http does - PHP-FIG focus on frameworks; pecl_http in core is useable without dependencies by every simple script - PSR-7 is a moving target; pecl_http exists for ten years - PSR-7 can be complementary to pecl_http not the other way around (c code can't use php code?) - native implementations should be faster General pros - PHP is made for Web. API like pecl_http should be included by default. - Script implementation and module implementation can co-exists. Example is mail/imap. Now I understand why many people dislike this proposal probably. Native module/script implementations may exist both. New module may be added/replaced at any time if it's required/reasonable. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] [RFC] [DISCUSSION] pecl_http
Hi Daniel! On 30 01 2015, at 07:28, Daniel Lowrey rdlow...@php.net wrote: Hi Mike :) I'd like to chime in on the discussion ... 1. There is a lot of *really* useful functionality in pecl/http that IMO should be bundled with the standard PHP distribution. This, to me, means things like parsing functionality that is conspicuously absent in a web-first language like PHP. HTTP messages, cookies, header parameters, multipart/form-data ... these are all standard HTTP elements for which we have no compiled parsing capabilities in the standard distribution. Adding this functionality in ext/http would be an instant win for my own work and I'm sure for many others as well. Moreover, parsing is the type of functionality that *really* benefits from being compiled as compared to happening in userland. Finally, this type of functionality is pretty vanilla and straightforward -- there is little room for stylistic disagreements in APIs and implementations. No one is going to complain that a multipart/form-data parser API is zomg so bad I need to tweet my frustration about #php right now. If it parses data how it's supposed to it's generally good enough. These are the kinds of things that ought to be bundled with the standard PHP distribution. They'd be a win for everyone and shouldn't realistically upset or confuse anyone. 2. There is some functionality here that isn't HTTP-specific and should exist in other extensions. I'm talking specifically here about the Encoding\Stream things. In fact, I had planned to PR essentially the same thing for ext/zlib between now and the 7 feature freeze. This is functionality that isn't specific to HTTP and belongs in ext/zlib, especially considering it relies on the zlib dependencies in the first place. I don't think it's a good idea to do this. It's missing functionality in another extension -- it should be PR'd and included there. PHP is well-known for its perceived lack of direction and this kind of overlap is exactly what people point to when they denigrate the language. If we already have these extensions lets update them instead of adding more extensions to cover holes in the existing ones. I'd personally prefer to see new development/inclusions take the wide view of the distribution as one whole PHP and not an incoherent mish-mash of overlapping extensions. 3. There is some functionality here that IMO belongs in pecl/ and not ext/ There are a lot of extras here. PHP's existing HTTP functionality is already spread all over the map and bundling this additional functionality certainly won't help to mitigate that. This ties in somewhat with my previous point, but ... we have superglobals, ext/curl, file_get_contents(), etc. Do we really need to bundle another extension that depends on curl to make HTTP requests? Do we really need to bring in two other pecl libs as hard dependencies for this? I don't really see enough benefit here to muddy the waters in such a way. Beyond this, http requests are IO-bound transactions ... this is something that can be done quite well (and is already) with existing userland libraries without incurring significant performance degradation. I don't see the need for all this extra stuff to add functionality that we already have. 4. There is some functionality here that will likely upset some people because it's subjective I'm speaking specifically about type abstractions like Message (and friends). This is functionality that provides very little performance benefit from being compiled and causes all sorts of disagreement and bikeshedding over API details. Obviously there's the whole PSR-7 thing happening right now which will be subjugated to any bundled HTTP abstractions in the standard distribution. While I personally have a lot of real problems with the API the FIG people are pushing, we certainly won't be making friends by adding a de facto standard HTTP API to the language with which they disagree. These are APIs which should be carefully considered at a community level in a web-first language. Short of that kind of consensus, I don't see how it's a good idea to bundle that kind of API with the rest of the language. ... So, in summary: If I had to take all of pecl/http or none of pecl/http right now ... I would vote, no, because while I want (and need) the capabilities from #1, I believe the associated drawbacks are too extensive to bring all the extra baggage into the standard PHP distribution. Thanks to anyone who read this phonebook of a mail all the way to the bottom! Thank you for taking the time to make your opinion public on internals, I appreciate. PHP should definitely take care to provide a reasonable API, but there’ll never be satisfaction for everyone. I think PHP is, and should be, a language where you’re more successful in getting things done, instead of having to do it right in one way only. This is not the end of the
