>> 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 :(
