Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81327
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.173 as permitted sender)
Sender: Michael Wallner <mike.php.net@gmail.com>
Message-ID: <54C9363D.6090102@php.net>
Date: Wed, 28 Jan 2015 20:19:25 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Matteo Beccati <php@beccati.com>, 
 PHP Internals <internals@lists.php.net>
References: <54C8D36E.7010803@php.net> <54C9338A.7020202@beccati.com>
In-Reply-To: <54C9338A.7020202@beccati.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 20:07, Matteo Beccati wrote:
> On 28/01/2015 13:17, Michael Wallner wrote:
>> Discussion has been very low on this topic since it was proposed on
>> August 19th, so I just opened the vote on the RFC whether to add
>> pecl_http to the core. The vote will be open until about 12:00 UTC on
>> Friday, February 6th.
>>
>> https://wiki.php.net/rfc/pecl_http#vote
> 
> Disclaimer: I'm not going to discuss the merits of the extension itself.
> I've never used it but I'm sure it's perfectly doing its job.
> 
> As Nikita mentions, PSR-7 is under way and currently gaining some
> traction. At the moment the PSR-7 interfaces are designed to be
> immutable, although I that's still open for debate. If the RFC passes,
> we'd be taking a fairly strong position and pushing the current
> pecl_http implementation as a de-facto standard. Sure, PHP-FIG would
> still be free to come up with their own standard, but it just doesn't
> seem much fair to me.

Why is everybody so obssessed by the word "standard"?
What is "fair" supposed to mean in this regard?

Doesn't FIG stand for Framework Interoperability Group? I've been there
and wanted to start a discussion on the topic, but without success.


> Also, we're planning to move extensions from core to pecl, for example
> ext/mysql which I is still widely used by many applications, despite its
> known shortcomings. TBH, I don't see many reasons why a pecl extension
> should be moved to core.

So that basically means, there shouldn't be any extension added to the
core any more, or only PECL ones?

> That's basically why I voted no earlier today.

Okay.

-- 
Regards,
Mike