Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81337
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain beccati.com designates 176.9.114.167 as permitted sender)
Message-ID: <54C94A9D.8000904@beccati.com>
Date: Wed, 28 Jan 2015 21:46:21 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Michael Wallner <mike@php.net>, 
 PHP Internals <internals@lists.php.net>
References: <54C8D36E.7010803@php.net> <54C9338A.7020202@beccati.com> <54C9363D.6090102@php.net>
In-Reply-To: <54C9363D.6090102@php.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] [VOTE] pecl_http
From: php@beccati.com (Matteo Beccati)

On 28/01/2015 20:19, Michael Wallner wrote:
> On 28/01/15 20:07, Matteo Beccati wrote:
>> 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.

Seen that too. Welcoming "BE GONE FOUL INTERNALS DEVELOPER" joke aside, 
some objections have been made. You didn't like them, you disappeared 
suggesting PHP-FIG to "play alone in your shady little shed".

Since PSR-7 is being discussed now *and* pecl_http can't implement an 
interface that still is being discussed, I would rather vote "no" now 
and maybe change my mind in future if PSR-7 becomes a thing and 
pecl_http follows. Or PSR-7 fails, for that matter.


>> 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?

pecl and (hopefully) pickle do a pretty good job at installing anything 
that's required. On the other hand distros offer packages for most of 
the core extensions anyway, even the ubiquitous zlib or json sometimes. 
So, yes I don't think core should have more extensions bundled, unless 
there's a very good reason. And I didn't see any yet.


Cheers
-- 
Matteo Beccati

Development & Consulting - http://www.beccati.com/