Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81339
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.175 as permitted sender)
Sender: Michael Wallner <mike.php.net@gmail.com>
Message-ID: <54C94B2B.1050505@php.net>
Date: Wed, 28 Jan 2015 21:48:43 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Stanislav Malyshev <smalyshev@gmail.com>
CC: PHP Internals <internals@lists.php.net>
References: <54C8D36E.7010803@php.net> <CAFMT4NpjFSycCVrSUfBBgfJEJv=4Yw8cpmQ-45JWf=75ptr8Lg@mail.gmail.com> <54C94774.8000709@gmail.com>
In-Reply-To: <54C94774.8000709@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] [VOTE] pecl_http
From: mike@php.net (Michael Wallner)

On 28/01/15 21:32, Stanislav Malyshev wrote:
> Hi!
> 
>> Some feedback: I feel the RFC is not clear about the advantages and
>> disadvantages of including this package. Mostly, the RFC is "hey I have
>> this package can we include it in core?" I feel like it's fairly incomplete
> 
> Agreed. There needs to be some work done on explaining why we need to
> include this in core, not just "ok, here's a bag of bits, do you want
> it?" Maybe we do, maybe we don't - but please, help us decide that! I'd
> like the RFC to clearly explain what the new extension does better and
> why.
> 
> Also, I see in the docs (which will need to be converted to docbook if
> it is added, btw) this:
> 
> This extension unconditionally depends on the pre-loaded presence of the
> following PHP extensions:
> 
> raphf
> propro
> spl
> 
> SPL is fine, but what's with the other two? Are they to be merged into
> core too? The RFC does not mention them and they seem to be some
> unrelated things which I personally have no idea about.

It was in the RFC, but they obviously vanished in the last edit...

I explained that in another mail and will put it (amongst a lot of other
things that came up during this thread) into the RFC:

---8<---
As stated in one of the discussion threads, those dependencies could be
merged to main/ and/or ext/standard. In the current patch the persistent
handle API is in main and the property proxy API is in ext/standard.

The resource factory and persistent handle API provides a similar but
extended set of functionality of what zend_list provides.

ZE2 compatible docs can currently be found here:
http://php.github.io/pecl-php-raphf/php__raphf_8h.html

The property proxy handles R/W access to object properties that
represent C struct members. Similar functionality was supposed to be in
ZE2, but disfunctional to my findings.

ZE2 compatible docs can currently be found here:
http://php.github.io/pecl-php-propro/php__propro_8h.html
--->8---

> 
> In general, I'd love to have great HTTP support in core, but let's do it
> right. The more time you as RFC author spend now on explaining why this
> ext is great, the more tools we'll have if it's accepted to get users to
> actually use it, and that's the ultimate point of it. Without it, we
> don't have adequate tools to make a decision and to support the users
> after the decision if it's positive.
> 

I'm a bad sales person, but I'll try better.


-- 
Regards,
Mike