Re: [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