On 1/28/15 2:46 PM, Matteo Beccati wrote:
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.
I actually quite like the idea of PHP core having HTTP message objects
built in, and a good HTTP client built in. These are both good things.
However, from the docs and the minimal RFC I really cannot say if
pecl_http is a good candidate for that. The current state-of-the-art
for those in the userspace world are PSR-7 (draft), and Guzzle (client),
which have been informing each other as they develop. It doesn't appear
on the surface as though the current RFC has been informed by those
processes.
I would much rather let that play out, and userspace verify that the
PSR-7 model (whatever it is) is what we actually want. Assuming it is,
or it would be with some tweak that we only find out once it's in
widespread use, we can move a nearly-identical model (or a
smartly-selected subset of it) into C code and benefit everyone. That's
something FIG and Internals can and should do collaboratively.
However, merging pecl_http now would effectively result in PHP releasing
two different, incompatible standards for HTTP handling in the same
year. That seems counter-productive. :-)
I don't have an Internals vote, but if I did I would be voting no at
this time. I'd rather revisit this in a year or two, in a
userspace/internals collaborative manner.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
