Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81366
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain devilix.net designates 209.85.218.47 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <54C9E5CC.8010607@beccati.com>
References: <54C8D36E.7010803@php.net>
	<54C9338A.7020202@beccati.com>
	<54C9363D.6090102@php.net>
	<54C94A9D.8000904@beccati.com>
	<CAPhkiZzzvhXgdhr83yZqUEz6igyesnnfBSK1PaK13gEAqHOz1A@mail.gmail.com>
	<54C9E5CC.8010607@beccati.com>
Date: Thu, 29 Jan 2015 11:41:38 +0200
Message-ID: <CAPhkiZyWjT7qUc2GvC40crqLiLNAA3MvJNXXTHg=nura3Eg-xw@mail.gmail.com>
To: Matteo Beccati <php@beccati.com>
Cc: Michael Wallner <mike@php.net>, PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC] [VOTE] pecl_http
From: narf@devilix.net (Andrey Andreev)

Hi,

On Thu, Jan 29, 2015 at 9:48 AM, Matteo Beccati <php@beccati.com> wrote:
> Hi Andrey,
>
> On 28/01/2015 23:50, Andrey Andreev wrote:
>>
>> You're voting "no" because the FIG can't agree yet?
>> They've been discussing this for *at least* an year and iirc the first
>> PSR-7 coordinator gave up on it because he no longer believed in the
>> end result. What does that tell us?
>
>
> That some actual work is finally being done now. Whether or not you, I or
> everyone else likes the direction it is going.
>
>> I'm not saying that you should vote "yes", but it's one thing to look
>> at the FIG for opinions/suggestions/inspiration and completely
>> different if you imply that they should dictate how a PHP core
>> extension is implemented.
>
>
> Indeed. But I am aware that an effort to have common Request/Response
> interfaces is under way and I'd like to see how that goes
> (opinions/suggestions/inspiration) before marrying to a specific, possibly
> incompatible, implementation (pecl_http in core).
>
>> PHP-FIG is not an authority and I too am quite annoyed by the
>> excessive usage of the word "standard" when referring to a "PSR". They
>> are not standards, they are recommendations written by a
>> self-appointed group of people and mostly for their own usage. A group
>> of mostly very smart people indeed, and important figures in the PHP
>> community too, but not an authority.
>
>
> Sure, "S" in PSR stands for Starndard, but "R" means Recommendation, but
> this is going slightly OT.
>

It's not about whether we like the FIG's direction or what "PSR"
stands for (which doesn't make sense btw) - that is indeed OT.

My message was different: the PHP RFC process can't get blocked
because of a third-party group, especially if your reasoning for that
is to follow "standards" which aren't standards at all.

Anyway, hopefully there will be more details on this RFC once voting
is restarted so we don't have to have such silly arguments.

Cheers,
Andrey.