Re: [RFC] [VOTE] pecl_http

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