Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:82386
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.179 as permitted sender)
Sender: Michael Wallner <mike.php.net@gmail.com>
Message-ID: <54DA3290.9010903@php.net>
Date: Tue, 10 Feb 2015 17:32:16 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Daniel Lowrey <rdlowrey@php.net>
CC: "internals@lists.php.net" <internals@lists.php.net>
References: <CAH8MpnnLnUgbgWM0o8MO8=a0bP==cbLapXmpTmEqO2iZYSS1gQ@mail.gmail.com>	<BD568277-5A74-4A66-AC5D-173DA93FA8FB@php.net> <CAH8MpnnOift5_zOk_XUP8iM2cxs80xQci8RspyqeWUNE+u9Vqw@mail.gmail.com>
In-Reply-To: <CAH8MpnnOift5_zOk_XUP8iM2cxs80xQci8RspyqeWUNE+u9Vqw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] [DISCUSSION] pecl_http
From: mike@php.net (Michael Wallner)

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