[RFC] [VOTE] pecl

Levi Morrison

11 years ago

>
> 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

I wish you had pinged the list before opening the vote. I know there were a
few people who wanted to make comments but have just been very busy. For
example, I have been dealing with the return types RFC which has soaked up
all of the time I have for working on PHP projects.

Some feedback: I feel the RFC is not clear about the advantages and
disadvantages of including this package. Mostly, the RFC is "hey I have
this package can we include it in core?" I feel like it's fairly incomplete
as to *why* we should include it. There is a fair amount of work done in
user-land for these types of utilities, and I think without a more balanced
discussion we'd be giving this extension a distinct advantage.

If we allow it to remain in voting phase despite these issues, I have to
vote no simply because I don't feel like there is enough information
presented in the RFC for anyone except current pecl_http users to make a
good decision; that's hardly a good situation for the language as a whole.

Levi Morrison

11 years ago

On Wed, Jan 28, 2015 at 10:53 AM, Levi Morrison <levim@php.net> 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
>
>
> I wish you had pinged the list before opening the vote. I know there were
> a few people who wanted to make comments but have just been very busy. For
> example, I have been dealing with the return types RFC which has soaked up
> all of the time I have for working on PHP projects.
>
> Some feedback: I feel the RFC is not clear about the advantages and
> disadvantages of including this package. Mostly, the RFC is "hey I have
> this package can we include it in core?" I feel like it's fairly incomplete
> as to *why* we should include it. There is a fair amount of work done in
> user-land for these types of utilities, and I think without a more balanced
> discussion we'd be giving this extension a distinct advantage.
>
> If we allow it to remain in voting phase despite these issues, I have to
> vote no simply because I don't feel like there is enough information
> presented in the RFC for anyone except current pecl_http users to make a
> good decision; that's hardly a good situation for the language as a whole.
>
>

Oh, one more item: has anyone had time to review the pieces and how they
all interact, as well as reviewing the quality of each component? I should
hardly think in the time given this has been done. I'm not saying this
extension is bad; I am saying that I don't think there's been time for
anyone to properly evaluate whether it is or not.

Andrew Faulds

11 years ago

Hi Levi,

> On 28 Jan 2015, at 17:58, Levi Morrison <levim@php.net> wrote:
>
> Oh, one more item: has anyone had time to review the pieces and how they
> all interact, as well as reviewing the quality of each component? I should
> hardly think in the time given this has been done. I'm not saying this
> extension is bad; I am saying that I don't think there's been time for
> anyone to properly evaluate whether it is or not.

Related to that: I should have asked about the size. By the looks of things pecl/http is a pretty big extension that covers an awful lot of functionality. The RFC’s lack of rationale for adding the extension is bad enough, but the size of the extension makes it worse. It’s a lot of classes (28 in total), so I think the RFC really needs a strong case to add all these different modules. Not only does the RFC need an overall rationale, but each module probably needs its own rationale: how does it compare to PHP’s existing functions for that feature, etc.?

Thanks.

--
Andrea Faulds
http://ajf.me/

Michael Wallner

11 years ago

On 28/01/15 19:03, Andrea Faulds wrote:

> Hi Levi,
>
>> On 28 Jan 2015, at 17:58, Levi Morrison <levim@php.net> wrote:
>>
>> Oh, one more item: has anyone had time to review the pieces and how
>> they all interact, as well as reviewing the quality of each
>> component? I should hardly think in the time given this has been
>> done. I'm not saying this extension is bad; I am saying that I
>> don't think there's been time for anyone to properly evaluate
>> whether it is or not.
>
> Related to that: I should have asked about the size. By the looks of
> things pecl/http is a pretty big extension that covers an awful lot
> of functionality. The RFC’s lack of rationale for adding the
> extension is bad enough, but the size of the extension makes it
> worse. It’s a lot of classes (28 in total), so I think the RFC really
> needs a strong case to add all these different modules. Not only does
> the RFC need an overall rationale, but each module probably needs its
> own rationale: how does it compare to PHP’s existing functions for
> that feature, etc.?

Yes, it's huge, but mostly only because PHP, the web language, lacks in
all of those areas. A quick overview of the top namespace:

- Client

The http stream wrapper is a hack and the existing libcurl binding is
subpar. They could be improved separately, but that is not subject of
this RFC.

Currently only libcurl is implemented as a provider for the client
functionality. Provides most of the functionality of current libcurl.
Representation of the request and response how a client sees them.
Support for parallel requests and optional libev{,ent} support.

- Cookie

Parses Cookie and Set-Cookie header values. Actually builds on http\Params.

- Encoding

Streamable implementations of chunked, zlib/gzip/deflate encodings.

- Env

Negotiation facilities, representations of the request and response how
the server sees them. Support for range requests and caching by
etag/last-modified.

- Header

Header parser and tools.

- Message

Message parser and tools. Also message bodies with support for building
and parsing multipart bodies.

- Params

Header params parser; think of a content-type or an accept header.

- QueryString

Query string parser and tools. Actually builds on http\Params.

- Url

URL parser and tools (actually discovered today, that it leans towards IRIs)

--
Regards,
Mike

Andrew Faulds

11 years ago

Hi Michael,

> On 28 Jan 2015, at 19:13, Michael Wallner <mike@php.net> wrote:
>
> - Client
>
> The http stream wrapper is a hack and the existing libcurl binding is
> subpar. They could be improved separately, but that is not subject of
> this RFC.
>
> Currently only libcurl is implemented as a provider for the client
> functionality. Provides most of the functionality of current libcurl.
> Representation of the request and response how a client sees them.
> Support for parallel requests and optional libev{,ent} support.

If the client is merely a wrapper around cURL, what benefit does it offer over ext/curl except a better API?

Personally, I’ve never liked that PHP requires cURL for doing HTTP requests. It’s a language made for the web, it should have built-in HTTP, and it should share code between its server-side HTTP and client-side HTTP stuff. I don’t think that the HTTP stream wrappers are a “hack” - they’re what PHP should have had all along. I think we should focus on improving them (so there’s no need to use cURL) rather than adding yet another HTTP client.

Thanks.

--
Andrea Faulds
http://ajf.me/

Michael Wallner

11 years ago

On 28/01/15 20:18, Andrea Faulds wrote:

> Hi Michael,
>
>> On 28 Jan 2015, at 19:13, Michael Wallner <mike@php.net> wrote:
>>
>> - Client
>>
>> The http stream wrapper is a hack and the existing libcurl binding
>> is subpar. They could be improved separately, but that is not
>> subject of this RFC.
>>
>> Currently only libcurl is implemented as a provider for the client
>> functionality. Provides most of the functionality of current
>> libcurl. Representation of the request and response how a client
>> sees them. Support for parallel requests and optional libev{,ent}
>> support.
>
> If the client is merely a wrapper around cURL, what benefit does it
> offer over ext/curl except a better API?
>
> Personally, I’ve never liked that PHP requires cURL for doing HTTP
> requests. It’s a language made for the web, it should have built-in
> HTTP, and it should share code between its server-side HTTP and
> client-side HTTP stuff. I don’t think that the HTTP stream wrappers
> are a “hack” - they’re what PHP should have had all along. I think we
> should focus on improving them (so there’s no need to use cURL)
> rather than adding yet another HTTP client.

Sounds a bit like NIH.
We could implement a http_client driver with the code from the stream
wrapper and see how they compare in feature set and performance.

--
Regards,
Mike

Andrew Faulds

11 years ago

Hi Michael,

> On 28 Jan 2015, at 19:48, Michael Wallner <mike@php.net> wrote:
>
> On 28/01/15 20:18, Andrea Faulds wrote:
>>
>> If the client is merely a wrapper around cURL, what benefit does it
>> offer over ext/curl except a better API?
>>
>> Personally, I’ve never liked that PHP requires cURL for doing HTTP
>> requests. It’s a language made for the web, it should have built-in
>> HTTP, and it should share code between its server-side HTTP and
>> client-side HTTP stuff. I don’t think that the HTTP stream wrappers
>> are a “hack” - they’re what PHP should have had all along. I think we
>> should focus on improving them (so there’s no need to use cURL)
>> rather than adding yet another HTTP client.
>
> Sounds a bit like NIH.

Ah, no, I hope I’m not misunderstood that way. My objection to cURL is that I don’t feel we should be using separate codebases for HTTP client stuff vs. HTTP server stuff. It doesn’t feel right to me that in such a web-focussed language we should have to use an external library for making HTTP requests - why can’t we use PHP’s own HTTP capabilities? IMO, they should be a single codebase. It’s needless duplication otherwise.

Thanks.

--
Andrea Faulds
http://ajf.me/

Stas Malyshev

11 years ago

Hi!

> Personally, I’ve never liked that PHP requires cURL for doing HTTP
> requests. It’s a language made for the web, it should have built-in

I see no problem in depending on cURL. NIH'ing every part of the
software universe in unfeasible, and if somebody does this one job and
does it well - why not use it? We don't have enough resources here to
implement every detail of the huge protocol like HTTP, and that's the
whole point of opensource to reuse and combine projects.

> HTTP, and it should share code between its server-side HTTP and
> client-side HTTP stuff. I don’t think that the HTTP stream wrappers
> are a “hack” - they’re what PHP should have had all along. I think we

HTTP stream wrappers work for some cases, but not for all and for cases
where you need deep involvement with details of HTTP - like headers,
byteranges, content encodings, etc. - they might not be the best API to
deal with it.

--
Stas Malyshev
smalyshev@gmail.com

Andrew Faulds

11 years ago

Hi Stas,

> On 28 Jan 2015, at 20:30, Stanislav Malyshev <smalyshev@gmail.com> wrote:
>
> Hi!
>
>> Personally, I’ve never liked that PHP requires cURL for doing HTTP
>> requests. It’s a language made for the web, it should have built-in
>
> I see no problem in depending on cURL. NIH'ing every part of the
> software universe in unfeasible, and if somebody does this one job and
> does it well - why not use it? We don't have enough resources here to
> implement every detail of the huge protocol like HTTP, and that's the
> whole point of opensource to reuse and combine projects.

I suppose cURL isn’t so bad… really, the API is the biggest issue with that. HTTP requests in PHP feel like a second-class citizen and must be done through an awkward set of PHP bindings to a C library. That’s awful for a language made for the web.

I’d be okay with cURL were it not for the API, I guess. Actually, if we’re to keep HTTP stream wrappers and keep using cURL, then the HTTP stream wrapper should probably also use cURL, right?

>> HTTP, and it should share code between its server-side HTTP and
>> client-side HTTP stuff. I don’t think that the HTTP stream wrappers
>> are a “hack” - they’re what PHP should have had all along. I think we
>
> HTTP stream wrappers work for some cases, but not for all and for cases
> where you need deep involvement with details of HTTP - like headers,
> byteranges, content encodings, etc. - they might not be the best API to
> deal with it.

This is true. The main thing I like about HTTP stream wrappers is that they’re part of core PHP rather than some external library. Also, they support headers, have done for ages.

Thanks.

--
Andrea Faulds
http://ajf.me/

Michael Wallner

11 years ago

On 28/01/15 18:58, Levi Morrison wrote:

> On Wed, Jan 28, 2015 at 10:53 AM, Levi Morrison <levim@php.net
> <mailto:levim@php.net>> 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
>
>
>     I wish you had pinged the list before opening the vote. I know there
>     were a few people who wanted to make comments but have just been
>     very busy. For example, I have been dealing with the return types
>     RFC which has soaked up all of the time I have for working on PHP
>     projects.
>
>     Some feedback: I feel the RFC is not clear about the advantages and
>     disadvantages of including this package. Mostly, the RFC is "hey I
>     have this package can we include it in core?" I feel like it's
>     fairly incomplete as to *why* we should include it. There is a fair
>     amount of work done in user-land for these types of utilities, and I
>     think without a more balanced discussion we'd be giving this
>     extension a distinct advantage.
>
>     If we allow it to remain in voting phase despite these issues, I
>     have to vote no simply because I don't feel like there is enough
>     information presented in the RFC for anyone except current pecl_http
>     users to make a good decision; that's hardly a good situation for
>     the language as a whole.
>
>
> Oh, one more item: has anyone had time to review the pieces and how they
> all interact, as well as reviewing the quality of each component? I
> should hardly think in the time given this has been done. I'm not saying
> this extension is bad; I am saying that I don't think there's been time
> for anyone to properly evaluate whether it is or not.

Well, there's been hardly any activity on the RFC for over five months,
if one didn't have the chance for review in this time frame then the
topic is probably not interesting enough for her.

But I already guessed, that there wouldn't be a real discussion until I
slapped the label VOTE on this RFC.

--
Regards,
Mike

Levi Morrison

11 years ago

On Wed, Jan 28, 2015 at 11:12 AM, Michael Wallner <mike@php.net> wrote:

> On 28/01/15 18:58, Levi Morrison wrote:
> > On Wed, Jan 28, 2015 at 10:53 AM, Levi Morrison <levim@php.net
> > <mailto:levim@php.net>> 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
> >
> >
> >     I wish you had pinged the list before opening the vote. I know there
> >     were a few people who wanted to make comments but have just been
> >     very busy. For example, I have been dealing with the return types
> >     RFC which has soaked up all of the time I have for working on PHP
> >     projects.
> >
> >     Some feedback: I feel the RFC is not clear about the advantages and
> >     disadvantages of including this package. Mostly, the RFC is "hey I
> >     have this package can we include it in core?" I feel like it's
> >     fairly incomplete as to *why* we should include it. There is a fair
> >     amount of work done in user-land for these types of utilities, and I
> >     think without a more balanced discussion we'd be giving this
> >     extension a distinct advantage.
> >
> >     If we allow it to remain in voting phase despite these issues, I
> >     have to vote no simply because I don't feel like there is enough
> >     information presented in the RFC for anyone except current pecl_http
> >     users to make a good decision; that's hardly a good situation for
> >     the language as a whole.
> >
> >
> > Oh, one more item: has anyone had time to review the pieces and how they
> > all interact, as well as reviewing the quality of each component? I
> > should hardly think in the time given this has been done. I'm not saying
> > this extension is bad; I am saying that I don't think there's been time
> > for anyone to properly evaluate whether it is or not.
>
> Well, there's been hardly any activity on the RFC for over five months,
> if one didn't have the chance for review in this time frame then the
> topic is probably not interesting enough for her.
>
> But I already guessed, that there wouldn't be a real discussion until I
> slapped the label VOTE on this RFC.
>

I always send an email to the list before putting something to vote to
gather more feedback. It usually solicits one or two more points of
discussion. This is not technically a requirement, but if it has has no
activity for 5 months what are the chances that it is on my mind? (Hint:
exactly zero)

As an RFC author if you want people to think about your RFC and discuss it
then on occasion you need to bring it up now and again.

Michael Wallner

11 years ago

On 28/01/15 21:03, Levi Morrison wrote:

> On Wed, Jan 28, 2015 at 11:12 AM, Michael Wallner <mike@php.net
> <mailto:mike@php.net>> wrote:
>
>     On 28/01/15 18:58, Levi Morrison wrote:
>     > On Wed, Jan 28, 2015 at 10:53 AM, Levi Morrison <levim@php.net <mailto:levim@php.net>
>     > <mailto:levim@php.net <mailto:levim@php.net>>> 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
>     >
>     >
>     >     I wish you had pinged the list before opening the vote. I know
>     there
>     >     were a few people who wanted to make comments but have just been
>     >     very busy. For example, I have been dealing with the return types
>     >     RFC which has soaked up all of the time I have for working on PHP
>     >     projects.
>     >
>     >     Some feedback: I feel the RFC is not clear about the
>     advantages and
>     >     disadvantages of including this package. Mostly, the RFC is "hey I
>     >     have this package can we include it in core?" I feel like it's
>     >     fairly incomplete as to *why* we should include it. There is a
>     fair
>     >     amount of work done in user-land for these types of utilities,
>     and I
>     >     think without a more balanced discussion we'd be giving this
>     >     extension a distinct advantage.
>     >
>     >     If we allow it to remain in voting phase despite these issues, I
>     >     have to vote no simply because I don't feel like there is enough
>     >     information presented in the RFC for anyone except current
>     pecl_http
>     >     users to make a good decision; that's hardly a good situation for
>     >     the language as a whole.
>     >
>     >
>     > Oh, one more item: has anyone had time to review the pieces and
>     how they
>     > all interact, as well as reviewing the quality of each component? I
>     > should hardly think in the time given this has been done. I'm not
>     saying
>     > this extension is bad; I am saying that I don't think there's been
>     time
>     > for anyone to properly evaluate whether it is or not.
>
>     Well, there's been hardly any activity on the RFC for over five months,
>     if one didn't have the chance for review in this time frame then the
>     topic is probably not interesting enough for her.
>
>     But I already guessed, that there wouldn't be a real discussion until I
>     slapped the label VOTE on this RFC.
>
>
> I always send an email to the list before putting something to vote to
> gather more feedback. It usually solicits one or two more points of
> discussion. This is not technically a requirement, but if it has has no
> activity for 5 months what are the chances that it is on my mind? (Hint:
> exactly zero)
>
> As an RFC author if you want people to think about your RFC and discuss
> it then on occasion you need to bring it up now and again.

Yep, I re-started discussion on January 22nd. Gathered the same
participants than the first discussion round.

--
Regards,
Mike

Andrew Faulds

11 years ago

Hi Levi,

> On 28 Jan 2015, at 17:53, Levi Morrison <levim@php.net> 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
>
>
> I wish you had pinged the list before opening the vote. I know there were a
> few people who wanted to make comments but have just been very busy. For
> example, I have been dealing with the return types RFC which has soaked up
> all of the time I have for working on PHP projects.
>
> Some feedback: I feel the RFC is not clear about the advantages and
> disadvantages of including this package. Mostly, the RFC is "hey I have
> this package can we include it in core?" I feel like it's fairly incomplete
> as to *why* we should include it. There is a fair amount of work done in
> user-land for these types of utilities, and I think without a more balanced
> discussion we'd be giving this extension a distinct advantage.
>
> If we allow it to remain in voting phase despite these issues, I have to
> vote no simply because I don't feel like there is enough information
> presented in the RFC for anyone except current pecl_http users to make a
> good decision; that's hardly a good situation for the language as a whole.

I completely agree here: reading the RFC I have little idea as to:

* What pecl/http actually is
* What pecl/http does
* How what pecl/http does differs from PHP’s existing facilities
* Why PHP should include pecl/http
* Why PHP should enable pecl/http by default

As it stands, I can’t see how it’s substantially different from our existing stuff in core, except maybe more OOP and a little more feature-complete. I’ve sort of gleaned this from looking at pecl/http’s docs… the RFC is barren, lacking in details about anything.

It really doesn’t make any case for itself, and I’m also concerned about possibly unnecessary implementation duplication. PHP already has several implementations of various aspects of the HTTP protocol, the RFC doesn’t explain why we need another.

So, like you, I’m probably going to vote No.

Thanks.

--
Andrea Faulds
http://ajf.me/

Stas Malyshev

11 years ago

Hi!

> Some feedback: I feel the RFC is not clear about the advantages and
> disadvantages of including this package. Mostly, the RFC is "hey I have
> this package can we include it in core?" I feel like it's fairly incomplete

Agreed. There needs to be some work done on explaining why we need to
include this in core, not just "ok, here's a bag of bits, do you want
it?" Maybe we do, maybe we don't - but please, help us decide that! I'd
like the RFC to clearly explain what the new extension does better and
why.

Also, I see in the docs (which will need to be converted to docbook if
it is added, btw) this:

This extension unconditionally depends on the pre-loaded presence of the
following PHP extensions:

raphf
propro
spl

SPL is fine, but what's with the other two? Are they to be merged into
core too? The RFC does not mention them and they seem to be some
unrelated things which I personally have no idea about.

In general, I'd love to have great HTTP support in core, but let's do it
right. The more time you as RFC author spend now on explaining why this
ext is great, the more tools we'll have if it's accepted to get users to
actually use it, and that's the ultimate point of it. Without it, we
don't have adequate tools to make a decision and to support the users
after the decision if it's positive.

--
Stas Malyshev
smalyshev@gmail.com

Michael Wallner

11 years ago

On 28/01/15 21:32, Stanislav Malyshev wrote:

> Hi!
>
>> Some feedback: I feel the RFC is not clear about the advantages and
>> disadvantages of including this package. Mostly, the RFC is "hey I have
>> this package can we include it in core?" I feel like it's fairly incomplete
>
> Agreed. There needs to be some work done on explaining why we need to
> include this in core, not just "ok, here's a bag of bits, do you want
> it?" Maybe we do, maybe we don't - but please, help us decide that! I'd
> like the RFC to clearly explain what the new extension does better and
> why.
>
> Also, I see in the docs (which will need to be converted to docbook if
> it is added, btw) this:
>
> This extension unconditionally depends on the pre-loaded presence of the
> following PHP extensions:
>
> raphf
> propro
> spl
>
> SPL is fine, but what's with the other two? Are they to be merged into
> core too? The RFC does not mention them and they seem to be some
> unrelated things which I personally have no idea about.

It was in the RFC, but they obviously vanished in the last edit...

I explained that in another mail and will put it (amongst a lot of other
things that came up during this thread) into the RFC:

---8<---
As stated in one of the discussion threads, those dependencies could be
merged to main/ and/or ext/standard. In the current patch the persistent
handle API is in main and the property proxy API is in ext/standard.

The resource factory and persistent handle API provides a similar but
extended set of functionality of what zend_list provides.

ZE2 compatible docs can currently be found here:
http://php.github.io/pecl-php-raphf/php__raphf_8h.html

The property proxy handles R/W access to object properties that
represent C struct members. Similar functionality was supposed to be in
ZE2, but disfunctional to my findings.

ZE2 compatible docs can currently be found here:
http://php.github.io/pecl-php-propro/php__propro_8h.html
--->8---

>
> In general, I'd love to have great HTTP support in core, but let's do it
> right. The more time you as RFC author spend now on explaining why this
> ext is great, the more tools we'll have if it's accepted to get users to
> actually use it, and that's the ultimate point of it. Without it, we
> don't have adequate tools to make a decision and to support the users
> after the decision if it's positive.
>

I'm a bad sales person, but I'll try better.

--
Regards,
Mike

Stas Malyshev

11 years ago

Hi!

> I explained that in another mail and will put it (amongst a lot of other
> things that came up during this thread) into the RFC:

This is not enough. Saying "ZE APIs suck, so I implemented a bunch of my
own and want to merge it in core because I like them" is not enough to
make an informed decision - why ZE APIs suck? Can we fix them without
introducing a bunch of new APIs? Are new APIs good for common case
beyond this particular extension?

It is not really feasible for each extension to use it's own API to deal
with resources or objects. So if we introduce a new one, we should have
clear understanding that a) existing ones are not enough and b) new one
would serve more than narrow need of one case.

> I'm a bad sales person, but I'll try better.

The community needs to take an informed decision. For that, we need the
information. You are the one who has the information, so please share
it! It is obvious you think that what you did is good - otherwise you
wouldn't propose it, and you probably know why exactly it is good - so
please tell us so we'd know too.

--
Stas Malyshev
smalyshev@gmail.com

Nikita Popov

11 years ago

On Wed, Jan 28, 2015 at 1:17 PM, Michael Wallner <mike@php.net> wrote:

> Hi,
>
> 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
>

I don't feel like this RFC leaves me in a position to make a qualified
choice as to whether this extension should be included or not. There's just
way too little information in here, and I don't think an extension like
this should be added lightly.

I understand that it may not be feasible to include full API design
documents in an RFC, but there's a lot of other things that just aren't
clear to me. A few random points:

* While the RFC does not mention it, I understand that pecl_http has hard
dependencies on two other extensions. What do these extensions do and how
is the integration in core supposed to be handled?
* The RFC mentioned that "pecl_http adds processing for json request
bodies into $_POST". Could you elaborate on this, in particular when this
is enabled and how automatic it is? Did you give proper consideration to
the security implications that this has? E.g. are you confident that the
implementation is HashDOS resistant?
* A number of libraries and frameworks already provide functionality that
intersects with parts of the pecl_http extension. There's also the upcoming
PSR-7 standard that might be of relevance. How does the API exposed by
pecl_http compare to these / follow existing APIs / standards?
* How does this extension relate to curl, in particular how is the
dependency situation and what happens when the dependency is not met? What
other optional dependencies are there?
* Why do we need to include these kinds of APIs directly into PHP instead
of the current situations where object oriented HTTP APIs are implemented
by libraries / frameworks and can evolve independently of PHP?

Generally I am not entirely convinced that we should be including any
"high-level" APIs in this direction. With the advent of Composer it is
trivial to include an HTTP library written in PHP. I'm generally not a fan
of including functionality in core if there is no strong reason why it
can't or shouldn't be implemented as a userland library. Including
something in core usually freezes it for all time and makes future
improvements very hard.

What I would be primarily interested in here is the addition of "low-level"
APIs for handling HTTP - in particular functions for parsing raw strings.
This is a performance sensitive part that can benefit from a C based
implementation. (While high-level APIs benefit less from C - or even
anti-benefit by being buggier and harder to adjust.)

TL;DR I need more info to make an informed choice.

Nikita

Michael Wallner

11 years ago

On 28/01/15 19:08, Nikita Popov wrote:

> On Wed, Jan 28, 2015 at 1:17 PM, Michael Wallner <mike@php.net
> <mailto:mike@php.net>> wrote:
>
>     Hi,
>
>     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
>
>
> I don't feel like this RFC leaves me in a position to make a qualified
> choice as to whether this extension should be included or not. There's
> just way too little information in here, and I don't think an extension
> like this should be added lightly.
>
> I understand that it may not be feasible to include full API design
> documents in an RFC, but there's a lot of other things that just aren't
> clear to me. A few random points:
>
>  * While the RFC does not mention it, I understand that pecl_http has
> hard dependencies on two other extensions. What do these extensions do
> and how is the integration in core supposed to be handled?

As stated in one of the discussion threads, those dependencies could be
merged to main/ and/or ext/standard. In the current patch the persistent
handle API is in main and the property proxy API is in ext/standard.

The resource factory and persistent handle API provides a similar but
extended set of functionality of what zend_list provides.

ZE2 compatible docs can currently be found here:
http://php.github.io/pecl-php-raphf/php__raphf_8h.html

The property proxy handles R/W access to object properties that
represent C struct members. Similar functionality was supposed to be in
ZE2, but disfunctional to my findings.

ZE2 compatible docs can currently be found here:
http://php.github.io/pecl-php-propro/php__propro_8h.html

>  * The RFC mentioned that "pecl_http adds processing for json request
> bodies into $_POST". Could you elaborate on this, in particular when
> this is enabled and how automatic it is? Did you give proper
> consideration to the security implications that this has? E.g. are you
> confident that the implementation is HashDOS resistant?

Not necessarily. It suffers from the same issues, if any, like
php_json_decode().

>  * A number of libraries and frameworks already provide functionality
> that intersects with parts of the pecl_http extension. There's also the
> upcoming PSR-7 standard that might be of relevance. How does the API
> exposed by pecl_http compare to these / follow existing APIs / standards?

The first release of pecl_http was exactly ten years ago and it has
evolved a lot, of course. So I'm not sure what it should have followed.

>  * How does this extension relate to curl, in particular how is the
> dependency situation and what happens when the dependency is not met?

libcurl is the only client provider currently, so if libcurl is not
available at build time, the client functionality is unavailable at
runtime (i.e. http\Client is not instantiatable).

> What other optional dependencies are there?

Optional build time dependecies are json, iconv and hash.
All of them not of major importance.

json: decoding application/json entities
iconv: translating query strings
hash: generating ETags for dynamic entities

>  * Why do we need to include these kinds of APIs directly into PHP
> instead of the current situations where object oriented HTTP APIs are
> implemented by libraries / frameworks and can evolve independently of PHP?

We don't need to. Including it in core was a topic every other year, but
I never felt it was ready before.

> Generally I am not entirely convinced that we should be including any
> "high-level" APIs in this direction. With the advent of Composer it is
> trivial to include an HTTP library written in PHP. I'm generally not a
> fan of including functionality in core if there is no strong reason why
> it can't or shouldn't be implemented as a userland library. Including
> something in core usually freezes it for all time and makes future
> improvements very hard.
>
> What I would be primarily interested in here is the addition of
> "low-level" APIs for handling HTTP - in particular functions for parsing
> raw strings. This is a performance sensitive part that can benefit from
> a C based implementation. (While high-level APIs benefit less from C -
> or even anti-benefit by being buggier and harder to adjust.)
>
> TL;DR I need more info to make an informed choice.

I really had a problem to imagine what people would have liked to read
in the RFC; all I could think of had a touch of cheesy commercials, so I
refrained from it and waited for a discussion to spoil, which obviously
never happened.

--
Regards,
Mike

Stas Malyshev

11 years ago

Hi!

> As stated in one of the discussion threads, those dependencies could be
> merged to main/ and/or ext/standard. In the current patch the persistent

This should be prominently part of the RFC, not buried in the threads.
Merging two extensions into ext/standard is not some tiny detail that
nobody cares about, it's putting stuff into PHP core that has to be
supported and accounted for by everybody.

> The resource factory and persistent handle API provides a similar but
> extended set of functionality of what zend_list provides.

Extended in which way? Why zend_list is not enough? Why it is preferable
to use this new extension to improving zend_list?

> The property proxy handles R/W access to object properties that
> represent C struct members. Similar functionality was supposed to be in
> ZE2, but disfunctional to my findings.

Why it is "disfunctional" and which findings prove it? ZE objects has a
number of handlers, why it is not enough to use them? Which capabilities
the new extension adds that did not exist before? Why it is preferable
to add new API to the core to extending existing APIs to support needed
use-cases?

I think the fact that the RFC fails to mention that this is also vote
for introducing two new APIs into the core, which have no direct
relation to HTTP, is a pretty big defect. I understand it is not
intentional, but voting on this RFC without clear realization that the
vote is actually on three things, two of which are core API
modifications and never mentioned in the RFC itself, is just wrong and
such RFC should have never been put to vote.

I understand making these two extensions clear puts an additional burden
on the RFC author, but that is what putting things into core involves,
especially thing that is this big - once it is in the core, everybody
shares the responsibility for it, especially the main/ parts which are
not something you can dismiss as private matter for the extension.

--
Stas Malyshev
smalyshev@gmail.com

Matteo Beccati

11 years ago

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.

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.

That's basically why I voted no earlier today.


Cheers

--
Matteo Beccati

Development & Consulting - http://www.beccati.com/

Michael Wallner

11 years ago

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

Lester Caine

11 years ago

On 28/01/15 19:19, Michael Wallner wrote:

>> 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?

Bundling more and more into core is a pointless exercise. If pecl_http
is any good then it will gain it's own traction in distribution space as
just another package that can be added. Unbundling and better management
of interoperability is starting to see some more support and management
of extensions in their own code space is going to make life a lot easier
in the long term!

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

Matteo Beccati

11 years ago

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/

Andrew Faulds

11 years ago

Hey everyone,

> On 28 Jan 2015, at 20:46, Matteo Beccati <php@beccati.com> wrote:
>
> 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.

Related to this: is it even possible for an internal class to rely on and formally, explicitly “implement” a userland interface? It’s all very well if PHP has a built-in implementation that follows PSR-7, but it would suck if you couldn’t pass an instance of that class to a function with a (hypothetical) psr7\HttpMessage type hint.

Userland libraries don’t have this issue: they all just require the PSR-7 interface package in their composer.json and all is well.

--
Andrea Faulds
http://ajf.me/

Stas Malyshev

11 years ago

Hi!

> Related to this: is it even possible for an internal class to rely on
> and formally, explicitly “implement” a userland interface? It’s all

It's probably not a very good idea - internal classes are supposed to be
alive at the start of the request, but the userland interfaces can't be
there yet. Also, what happens if you try to use the internal class but
userland interface is not there yet? I don't think it is a feasible thing.

> very well if PHP has a built-in implementation that follows PSR-7,
> but it would suck if you couldn’t pass an instance of that class to a
> function with a (hypothetical) psr7\HttpMessage type hint.

You could, in theory, have extension defining those interfaces and
autoload userland definitions only if the extension is not present.

--
Stas Malyshev
smalyshev@gmail.com

Matteo Beccati

11 years ago

On 28/01/2015 22:03, Stanislav Malyshev wrote:

> You could, in theory, have extension defining those interfaces and
> autoload userland definitions only if the extension is not present.

That's basically what I meant. Thanks for clarifying.

Cheers

--
Matteo Beccati

Development & Consulting - http://www.beccati.com/

Larry Garfield

11 years ago

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

Andrey Andreev

11 years ago

Hi,

On Wed, Jan 28, 2015 at 10:46 PM, Matteo Beccati <php@beccati.com> 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.
>

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?

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.

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.

Cheers,
Andrey.

Dan Ackroyd

11 years ago

On 28 January 2015 at 22:50, Andrey Andreev <narf@devilix.net> 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 things are really, really hard to get right.

cheers
Dan

Matteo Beccati

11 years ago

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.


Cheers

--
Matteo Beccati

Development & Consulting - http://www.beccati.com/

Andrey Andreev

11 years ago

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.

Matteo Beccati

11 years ago

Hi Andrey,

On 29/01/2015 10:41, Andrey Andreev wrote:

> 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.

I'm not sure why you're turning this into a crusade against FIG and
PSRs. Your argument is valid, but I'm afraid that's the message you
conveyed much louder than the actual argument itself.

I didn't ask to block the RFC. I simply voted "no" to the RFC and
explained why I did that on the list, as it's expected from anyone who does.

The vote has since been cancelled. The next time it is opened, I would
love to read in the RFC why this implementation is better than any
userland attempt at it, be it PSR-7 or not.


Cheers

--
Matteo Beccati

Development & Consulting - http://www.beccati.com/

Andrey Andreev

11 years ago

Hi,

On Thu, Jan 29, 2015 at 12:52 PM, Matteo Beccati <php@beccati.com> wrote:

> Hi Andrey,
>
> On 29/01/2015 10:41, Andrey Andreev wrote:
>>
>> 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.
>
>
> I'm not sure why you're turning this into a crusade against FIG and PSRs.
> Your argument is valid, but I'm afraid that's the message you conveyed much
> louder than the actual argument itself.
>

My last message was intended to clarify that this is *not* a rant
about the FIG or PSRs, but a concern about proper reasoning in votes.

I didn't want to have another reply because this is all off-topic at
this point, but now you insist that I am in fact having a crusade
against PHP-FIG - I'm not, sorry if that wasn't clear enough. Let's
leave it at that please.

Cheers,
Andrey.

Pavel Kouřil

11 years ago

On Wed, Jan 28, 2015 at 1:17 PM, Michael Wallner <mike@php.net> wrote:

> Hi,
>
> 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
>
>
> --
> Regards,
> Mike
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Hello,

just one observation - would be the name of the classes and namespaces
stay the same after merging? I personally find the lowercased
namespace name kinda weird, given that most of code written in PHP
I've seen is using CamelCase.

Maybe there should be an RFC which would standardize naming and etc.
for future features?



Regards
Pavel Kouril

Martin Keckeis

11 years ago

2015-01-29 14:07 GMT+01:00 Pavel Kouřil <pajousek@gmail.com>:

> On Wed, Jan 28, 2015 at 1:17 PM, Michael Wallner <mike@php.net> wrote:
> > Hi,
> >
> > 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
> >
> >
> > --
> > Regards,
> > Mike
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
>
> Hello,
>
> just one observation - would be the name of the classes and namespaces
> stay the same after merging? I personally find the lowercased
> namespace name kinda weird, given that most of code written in PHP
> I've seen is using CamelCase.
>
> Maybe there should be an RFC which would standardize naming and etc.
> for future features?
>
>
>
> Regards
> Pavel Kouril
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

+1 on that if the component getting merged. Would also be fine if the rest
would follow PSR1+2 (for the public signatures only of course)

Tony Marston

11 years ago

""Pavel Kouril""  wrote in message
news:CAB6YZuzyMBAa5i3f9NsvebG2B7YJvO4RyVpy-eac78rsOJxdhQ@mail.gmail.com...

>
>On Wed, Jan 28, 2015 at 1:17 PM, Michael Wallner <mike@php.net> wrote:
>> Hi,
>>

<snip>>

>Hello,
>
>just one observation - would be the name of the classes and namespaces
>stay the same after merging? I personally find the lowercased
>namespace name kinda weird, given that most of code written in PHP
>I've seen is using CamelCase.

Just because that most of the code YOU have seen uses CamelCase does not
mean that CamelCase is the "standard". I programmed in other languages for
over 20 years before I switched to PHP, and in those languages the standard
was snake_case. That is the standard I still use, and I will object most
strongly to the notion that I should change the habits of a lifetime just to
suit the personal preferences of a junior programmer. By "junior" I mean
"years of experience", not "job title".

--
Tony Marston

Yasuo Ohgaki

11 years ago

Hi Tony,

On Fri, Jan 30, 2015 at 7:08 PM, Tony Marston <TonyMarston@hotmail.com>
wrote:

> ""Pavel Kouril""  wrote in message
> news:CAB6YZuzyMBAa5i3f9NsvebG2B7YJvO4RyVpy-eac78rsOJxdhQ@mail.gmail.com...
>
>>
>> On Wed, Jan 28, 2015 at 1:17 PM, Michael Wallner <mike@php.net> wrote:
>>
>>> Hi,
>>>
>>>
> <snip>>
>
>  Hello,
>>
>> just one observation - would be the name of the classes and namespaces
>> stay the same after merging? I personally find the lowercased
>> namespace name kinda weird, given that most of code written in PHP
>> I've seen is using CamelCase.
>>
>
> Just because that most of the code YOU have seen uses CamelCase does not
> mean that CamelCase is the "standard". I programmed in other languages for
> over 20 years before I switched to PHP, and in those languages the standard
> was snake_case. That is the standard I still use, and I will object most
> strongly to the notion that I should change the habits of a lifetime just
> to
> suit the personal preferences of a junior programmer. By "junior" I mean
> "years of experience", not "job title".
>

We have coding standard.

From the CODING_STANDARDS in source.

6.  Method names follow the 'studlyCaps' (also referred to as 'bumpy case'
or 'camel caps') naming convention, with care taken to minimize the
letter count. The initial letter of the name is lowercase, and each
letter that starts a new 'word' is capitalized::

Good:
'connect()'
'getData()'
'buildSomeWidget()'

Bad:
'get_Data()'
'buildsomewidget'
'getI()'

7.  Classes should be given descriptive names. Avoid using abbreviations
where
possible. Each word in the class name should start with a capital
letter,
without underscore delimiters (CamelCaps starting with a capital
letter).
The class name should be prefixed with the name of the 'parent set'
(e.g.
the name of the extension)::

Good:
'Curl'
'FooBar'

Bad:
'foobar'
'foo_bar'

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

Tony Marston

11 years ago

"Yasuo Ohgaki"  wrote in message
news:CAGa2bXZGLjrp6i2VDnkdgA8Dw7NothC9iE17tsT40kpbbhA9FA@mail.gmail.com...

>
>Hi Tony,
>
>On Fri, Jan 30, 2015 at 7:08 PM, Tony Marston <TonyMarston@hotmail.com>
>wrote:
>
>> ""Pavel Kouril""  wrote in message
>> news:CAB6YZuzyMBAa5i3f9NsvebG2B7YJvO4RyVpy-eac78rsOJxdhQ@mail.gmail.com...
>>
>>>
>>> On Wed, Jan 28, 2015 at 1:17 PM, Michael Wallner <mike@php.net> wrote:
>>>
>> <snip>>
>>
>>  Hello,
>>>
>>> just one observation - would be the name of the classes and namespaces
>>> stay the same after merging? I personally find the lowercased
>>> namespace name kinda weird, given that most of code written in PHP
>>> I've seen is using CamelCase.
>>>
>>
>> Just because that most of the code YOU have seen uses CamelCase does not
>> mean that CamelCase is the "standard". I programmed in other languages
>> for
>> over 20 years before I switched to PHP, and in those languages the
>> standard
>> was snake_case. That is the standard I still use, and I will object most
>> strongly to the notion that I should change the habits of a lifetime just
>> to
>> suit the personal preferences of a junior programmer. By "junior" I mean
>> "years of experience", not "job title".
>>
>
>We have coding standard.
>
>From the CODING_STANDARDS in source.
>
>6.  Method names follow the 'studlyCaps' (also referred to as 'bumpy case'
>    or 'camel caps') naming convention

<snip>>

>7.  Classes should be given descriptive names. Avoid using abbreviations
>    where  possible. Each word in the class name should start with a
> capital
>    letter,  without underscore delimiters (CamelCaps starting with a
> capital
>    letter).  The class name should be prefixed with the name of the
> 'parent
>    set' (e.g.  the name of the extension)::
>

<<snip>>

If you are talking about coding standards which apply to PHP core then that
is one thing, but trying to enforce those standards in userland code would
be completely unacceptable.

--
Tony Marston

Pierre Joye

11 years ago

On Jan 31, 2015 5:57 PM, "Tony Marston" <TonyMarston@hotmail.com> wrote:

>
> "Yasuo Ohgaki"  wrote in message

news:CAGa2bXZGLjrp6i2VDnkdgA8Dw7NothC9iE17tsT40kpbbhA9FA@mail.gmail.com...

>>
>>
>> Hi Tony,
>>
>> On Fri, Jan 30, 2015 at 7:08 PM, Tony Marston <TonyMarston@hotmail.com>
>> wrote:
>>
>>> ""Pavel Kouril""  wrote in message
>>> news:CAB6YZuzyMBAa5i3f9NsvebG2B7YJvO4RyVpy-eac78rsOJxdhQ@mail.gmail.com.

..

>>>
>>>>
>>>> On Wed, Jan 28, 2015 at 1:17 PM, Michael Wallner <mike@php.net> wrote:
>>>>
>>> <snip>>
>>>
>>>  Hello,
>>>>
>>>>
>>>> just one observation - would be the name of the classes and namespaces
>>>> stay the same after merging? I personally find the lowercased
>>>> namespace name kinda weird, given that most of code written in PHP
>>>> I've seen is using CamelCase.
>>>>
>>>
>>> Just because that most of the code YOU have seen uses CamelCase does not
>>> mean that CamelCase is the "standard". I programmed in other languages

for

>>> over 20 years before I switched to PHP, and in those languages the

standard

>>> was snake_case. That is the standard I still use, and I will object most
>>> strongly to the notion that I should change the habits of a lifetime

just to

>>> suit the personal preferences of a junior programmer. By "junior" I mean
>>> "years of experience", not "job title".
>>>
>>
>> We have coding standard.
>>
>> From the CODING_STANDARDS in source.
>>
>> 6.  Method names follow the 'studlyCaps' (also referred to as 'bumpy

case'

>>    or 'camel caps') naming convention
>
>
> <snip>>
>
>
>> 7.  Classes should be given descriptive names. Avoid using abbreviations
>>    where  possible. Each word in the class name should start with a

capital

>>    letter,  without underscore delimiters (CamelCaps starting with a

capital

>>    letter).  The class name should be prefixed with the name of the

'parent

>>    set' (e.g.  the name of the extension)::
>>
> <<snip>>
>
> If you are talking about coding standards which apply to PHP core then

that is one thing, but trying to enforce those standards in userland code
would be completely unacceptable.

>
>

This is a discussion about adding features to core. They have to follow our
CS. Period. There is nothing to discuss here.

Sorry to sound harsh but this is going far OT. I would prefer to focus on
the features and implementation details instead of that.

Larry Garfield

11 years ago

On 1/30/15 4:08 AM, Tony Marston wrote:

> ""Pavel Kouril""  wrote in message
> news:CAB6YZuzyMBAa5i3f9NsvebG2B7YJvO4RyVpy-eac78rsOJxdhQ@mail.gmail.com...
>>
>> On Wed, Jan 28, 2015 at 1:17 PM, Michael Wallner <mike@php.net> wrote:
>>> Hi,
>>>
>
> <snip>>
>
>> Hello,
>>
>> just one observation - would be the name of the classes and namespaces
>> stay the same after merging? I personally find the lowercased
>> namespace name kinda weird, given that most of code written in PHP
>> I've seen is using CamelCase.
>
> Just because that most of the code YOU have seen uses CamelCase does not
> mean that CamelCase is the "standard". I programmed in other languages for
> over 20 years before I switched to PHP, and in those languages the standard
> was snake_case. That is the standard I still use, and I will object most
> strongly to the notion that I should change the habits of a lifetime
> just to
> suit the personal preferences of a junior programmer. By "junior" I mean
> "years of experience", not "job title".

Core uses CamelCase class names.  The overwhelming majority of the PHP
code I've seen in the wild uses CamelCase for both classes and
namespaces.  Other languages certainly have other conventions, but this
is PHP.  This isn't "personal preference of a junior programmer" (which
is a rather flippant way to dismiss a fellow developer you do not know).
It's the convention used by most of an industry.

Please get off your high horse.  You look quite silly up there.

--Larry Garfield

Tony Marston

11 years ago

"Larry Garfield"  wrote in message news:54CBB0CD.9010707@garfieldtech.com...

>
>On 1/30/15 4:08 AM, Tony Marston wrote:
>> ""Pavel Kouril""  wrote in message
>> news:CAB6YZuzyMBAa5i3f9NsvebG2B7YJvO4RyVpy-eac78rsOJxdhQ@mail.gmail.com...
>>>
>>> On Wed, Jan 28, 2015 at 1:17 PM, Michael Wallner <mike@php.net> wrote:
>>>
>>> just one observation - would be the name of the classes and namespaces
>>> stay the same after merging? I personally find the lowercased
>>> namespace name kinda weird, given that most of code written in PHP
>>> I've seen is using CamelCase.
>>
>> Just because that most of the code YOU have seen uses CamelCase does not
>> mean that CamelCase is the "standard". I programmed in other languages
>> for
>> over 20 years before I switched to PHP, and in those languages the
>> standard
>> was snake_case. That is the standard I still use, and I will object most
>> strongly to the notion that I should change the habits of a lifetime just
>> to
>> suit the personal preferences of a junior programmer. By "junior" I mean
>> "years of experience", not "job title".
>
>Core uses CamelCase class names.  The overwhelming majority of the PHP code
>I've seen in the wild uses CamelCase for both classes and namespaces.

I'm afraid that "code that I have seen" is only a small fraction of all the
"code that has been written". I use snake_case simply because it was the
standard in those language which I used in the 20 years before switching to
PHP. PHP has never enforced any particular naming convention, nor should it.
Thus I am free to whatever I please, whether it be snake_case, camelCase,
StudlyCaps or whatever.

> Other languages certainly have other conventions, but this is PHP.

It is not up to the language to dictate coding style or naming conventions,
that is entirely the domain of each group of programmers.

>This isn't "personal preference of a junior programmer" (which is a rather
>flippant way to dismiss a fellow developer you do not know).

I have been in the software industry for over 35 years, and I have
encountered many different standards, some good, some bad. The standards
that I still use today are based on all the better parts from those
individual standards. I object most strongly to a programmer who has far
less experience than me suddenly telling me that I must change the habits of
a lifetime so that my coding style conforms to his personal preferences.
Such arrogance!

>It's the convention used by most of an industry.

How do you know that it "most of the industry"? Snake_case existed for years
before camelCase was invented, and is still used by many. It is even evident
in PHP itself, so your assertion is just a personal opinion and not a fact.

--
Tony Marston

Pierre Joye

11 years ago

On Jan 30, 2015 6:09 PM, "Tony Marston" <TonyMarston@hotmail.com> wrote:

>
> ""Pavel Kouril""  wrote in message
> news:CAB6YZuzyMBAa5i3f9NsvebG2B7YJvO4RyVpy-eac78rsOJxdhQ@mail.gmail.com...
>
>>
>> On Wed, Jan 28, 2015 at 1:17 PM, Michael Wallner <mike@php.net> wrote:
>>>
>>> Hi,
>>>
>
> <snip>>
>
>
>> Hello,
>>
>> just one observation - would be the name of the classes and namespaces
>> stay the same after merging? I personally find the lowercased
>> namespace name kinda weird, given that most of code written in PHP
>> I've seen is using CamelCase.
>
>
> Just because that most of the code YOU have seen uses CamelCase does not
> mean that CamelCase is the "standard". I programmed in other languages for
> over 20 years before I switched to PHP, and in those languages the

standard

> was snake_case. That is the standard I still use, and I will object most
> strongly to the notion that I should change the habits of a lifetime just

to

> suit the personal preferences of a junior programmer. By "junior" I mean
> "years of experience", not "job title".

There is zero reason to discuss what has been approved and followed for
years already.

I will simply post the link to our CS as a reminder and ask everyone to
read it if they never did:

https://github.com/php/php-src/blob/master/CODING_STANDARDS

Pavel Kouřil

11 years ago

On Sat, Jan 31, 2015 at 1:41 PM, Pierre Joye <pierre.php@gmail.com> wrote:

>
> There is zero reason to discuss what has been approved and followed for
> years already.
>
> I will simply post the link to our CS as a reminder and ask everyone to
> read it if they never did:
>
> https://github.com/php/php-src/blob/master/CODING_STANDARDS

Well, the coding standard doesn't mention namespaces. So shouldn't it
be updated to include namespaces? If there's an RFC for including
something using namespaces, the should be rules for naming namespaces
in the coding standard, IMHO.

Pavel Kouril

Pierre Joye

11 years ago

On Jan 31, 2015 9:08 PM, "Pavel Kouřil" <pajousek@gmail.com> wrote:

>
> On Sat, Jan 31, 2015 at 1:41 PM, Pierre Joye <pierre.php@gmail.com> wrote:
> >
> > There is zero reason to discuss what has been approved and followed for
> > years already.
> >
> > I will simply post the link to our CS as a reminder and ask everyone to
> > read it if they never did:
> >
> > https://github.com/php/php-src/blob/master/CODING_STANDARDS
>
> Well, the coding standard doesn't mention namespaces. So shouldn't it
> be updated to include namespaces? If there's an RFC for including
> something using namespaces, the should be rules for naming namespaces
> in the coding standard, IMHO.

It sounds pretty obvious but yes it should be mentioned for completeness.

Yasuo Ohgaki

11 years ago

Hi all,

On Sat, Jan 31, 2015 at 10:48 PM, Pierre Joye <pierre.php@gmail.com> wrote:

> On Jan 31, 2015 9:08 PM, "Pavel Kouřil" <pajousek@gmail.com> wrote:
> >
> > On Sat, Jan 31, 2015 at 1:41 PM, Pierre Joye <pierre.php@gmail.com>
> wrote:
> > >
> > > There is zero reason to discuss what has been approved and followed for
> > > years already.
> > >
> > > I will simply post the link to our CS as a reminder and ask everyone to
> > > read it if they never did:
> > >
> > > https://github.com/php/php-src/blob/master/CODING_STANDARDS
> >
> > Well, the coding standard doesn't mention namespaces. So shouldn't it
> > be updated to include namespaces? If there's an RFC for including
> > something using namespaces, the should be rules for naming namespaces
> > in the coding standard, IMHO.
>
> It sounds pretty obvious but yes it should be mentioned for completeness.

+1

I don't want to see no more methods names like __set_state, create_sid,
function
names like gd*(), and of course strange namespaces.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

Tony Marston

11 years ago

""Pavel Kouril""  wrote in message
news:CAB6YZuzyMBAa5i3f9NsvebG2B7YJvO4RyVpy-eac78rsOJxdhQ@mail.gmail.com...

>
>On Wed, Jan 28, 2015 at 1:17 PM, Michael Wallner <mike@php.net> wrote:
>> Hi,
>>

<snip>>

>Hello,
>
>just one observation - would be the name of the classes and namespaces
>stay the same after merging? I personally find the lowercased
>namespace name kinda weird, given that most of code written in PHP
>I've seen is using CamelCase.

Just because that most of the code YOU have seen uses CamelCase does not
mean that CamelCase is the "standard". I programmed in other languages for
over 20 years before I switched to PHP, and in those languages the standard
was snake_case. That is the standard I still use, and I will object most
strongly to the notion that I should change the habits of a lifetime just to
suit the personal preferences of a junior programmer. By "junior" I mean
"years of experience", not "job title".

--
Tony Marston

Stas Malyshev

11 years ago

Hi!

> Just because that most of the code YOU have seen uses CamelCase does not
> mean that CamelCase is the "standard". I programmed in other languages for
> over 20 years before I switched to PHP, and in those languages the standard
> was snake_case. That is the standard I still use, and I will object most
> strongly to the notion that I should change the habits of a lifetime
> just to
> suit the personal preferences of a junior programmer. By "junior" I mean
> "years of experience", not "job title".

Tony, the question here is not the style of your personal code base,
which is of course you have the full right to choose as you see fit. The
question is the style of the code in PHP core codebase, which is
maintained by dozens of people and used by millions. For such a code
base, consistent style helps both usability and maintainability, and
while a competent programmer would be able to read and produce code with
any style, having a consistent one would save the effort, which,
multiplied by the number of people using and maintaining the code, adds
up to a significant amount.

I'd say lowercase "http" namespace does look a bit weird to me and I'd
expect something like Http or HTTP as a namespace name, but that may be
open to debate since we don't have yet a tradition of namespace naming
in the core. Once we have such tradition, the extensions would be
expected to follow it, at least the core ones.

--
Stas Malyshev
smalyshev@gmail.com

Michael Wallner

11 years ago

On 30/01/15 20:19, Stanislav Malyshev wrote:

> Hi!
>
>> Just because that most of the code YOU have seen uses CamelCase does not
>> mean that CamelCase is the "standard". I programmed in other languages for
>> over 20 years before I switched to PHP, and in those languages the standard
>> was snake_case. That is the standard I still use, and I will object most
>> strongly to the notion that I should change the habits of a lifetime
>> just to
>> suit the personal preferences of a junior programmer. By "junior" I mean
>> "years of experience", not "job title".
>
> Tony, the question here is not the style of your personal code base,
> which is of course you have the full right to choose as you see fit. The
> question is the style of the code in PHP core codebase, which is
> maintained by dozens of people and used by millions. For such a code
> base, consistent style helps both usability and maintainability, and
> while a competent programmer would be able to read and produce code with
> any style, having a consistent one would save the effort, which,
> multiplied by the number of people using and maintaining the code, adds
> up to a significant amount.
>
> I'd say lowercase "http" namespace does look a bit weird to me and I'd
> expect something like Http or HTTP as a namespace name, but that may be
> open to debate since we don't have yet a tradition of namespace naming
> in the core. Once we have such tradition, the extensions would be
> expected to follow it, at least the core ones.

Exactly, and because this is still PHP and only autoloaders care about
those cases, the following is perfectly valid code:

<?php

USE HTTP\MESSAGE;

$MSG = NEW MESSAGE("HTTP/1.1 200 OK, BUT BIG");

?>

--
Regards,
Mike

Tony Marston

11 years ago

"Stanislav Malyshev"  wrote in message news:54CBD947.7050700@gmail.com...

>
>Hi!
>
>> Just because that most of the code YOU have seen uses CamelCase does not
>> mean that CamelCase is the "standard". I programmed in other languages
>> for
>> over 20 years before I switched to PHP, and in those languages the
>> standard
>> was snake_case. That is the standard I still use, and I will object most
>> strongly to the notion that I should change the habits of a lifetime
>> just to
>> suit the personal preferences of a junior programmer. By "junior" I mean
>> "years of experience", not "job title".
>
>Tony, the question here is not the style of your personal code base,
>which is of course you have the full right to choose as you see fit. The
>question is the style of the code in PHP core codebase

Thank you for clarifying what was not obvious in that post.

--
Tony Marston

Tony Marston

11 years ago

""Pavel Kouril""  wrote in message
news:CAB6YZuzyMBAa5i3f9NsvebG2B7YJvO4RyVpy-eac78rsOJxdhQ@mail.gmail.com...

>
>On Wed, Jan 28, 2015 at 1:17 PM, Michael Wallner <mike@php.net> wrote:
>> Hi,
>>

<snip>>

>Hello,
>
>just one observation - would be the name of the classes and namespaces
>stay the same after merging? I personally find the lowercased
>namespace name kinda weird, given that most of code written in PHP
>I've seen is using CamelCase.

Just because that most of the code YOU have seen uses CamelCase does not
mean that CamelCase is the "standard". I programmed in other languages for
over 20 years before I switched to PHP, and in those languages the standard
was snake_case. That is the standard I still use, and I will object most
strongly to the notion that I should change the habits of a lifetime just to
suit the personal preferences of a junior programmer. By "junior" I mean
"years of experience", not "job title".

--
Tony Marston

Julien Pauli

11 years ago

On Wed, Jan 28, 2015 at 1:17 PM, Michael Wallner <mike@php.net> wrote:

> Hi,
>
> 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
>
>

Great debate in here. I did read all the answers and I agree with many.
My opinions summed-up :

- PHP is a web language, and if there is one thing that must be done right,
it's to provide a rich-efficient-easy-to-extend HTTP API to our users,
which with our actual stream wrappers, is not really the case.

- Why not use Curl ? I fully agree with Stas message here : Curl is the
open-source defacto library you bind against when you want to manage HTTP
messages (and many other layer-7 formats). Many many opensource projects
already binds it. Curl is rich, stable, opensource; cross platform,
efficient and supported by many companies. To answer Andrea : our HTTP
stream wrapper layer used to be able to use curl wrappers, we dropped such
a support in 5.6 AFAIR, because it was beeing experimental for years, and
nobody maintained this.
* In addition to that : Curl is actively working on the next HTTP2
standard. If we, PHP, were using it, we would immediately be compatible
with HTTP2 when it is released, without much effort.

- pecl_http is rich. I'm not saying I'd have vote +1 to it, but from the
very first start I used PHP, about 10y ago, I've always wondered why
pecl_http wasn't a core de-facto extension. Just try to play with HTTP
negociation or HTTP partial messages with vanilla PHP (without pecl_http)
and you'll see what PITA it is.  Look at Java interfaces (example :
https://tomcat.apache.org/tomcat-5.5-doc/servletapi/javax/servlet/http/package-summary.html),
they are not perfect, but they are clean, clear, OOP designed APIS. PHP
current HTTP API just makes me scared.

- And finally, probably the most important thing => I'm all +1 with Andrea
, saying that we have way too many places into PHP source code where HTTP
has been yet-once-again reimplemented. This is WRONG from a software
development POV. Easy as this. Have a look at ext/SAOP, at php-fpm, at PHP
streams .... So many duplicated code about handling HTTP. We suffer from
that (bug fixed in one place but not the other one). We absolutely need to
design a low level HTTP API at one unique place (ext/standard?) and reuse
it everywhere as well as provide userland access to it, like we've done for
so many dfferent things so far, but HTTP ....


Julien.Pauli

[RFC] [VOTE] pecl_http

Michael Wallner

Levi Morrison

Levi Morrison

Andrew Faulds

Michael Wallner

Andrew Faulds

Michael Wallner

Andrew Faulds

Stas Malyshev

Andrew Faulds

Michael Wallner

Levi Morrison

Michael Wallner

Andrew Faulds

Stas Malyshev

Michael Wallner

Stas Malyshev

Nikita Popov

Michael Wallner

Stas Malyshev

Matteo Beccati

Michael Wallner

Lester Caine

Matteo Beccati

Andrew Faulds

Stas Malyshev

Matteo Beccati

Larry Garfield

Andrey Andreev

Dan Ackroyd

Matteo Beccati

Andrey Andreev

Matteo Beccati

Andrey Andreev

Pavel Kouřil

Martin Keckeis

Tony Marston

Yasuo Ohgaki

Tony Marston

Pierre Joye

Larry Garfield

Tony Marston

Pierre Joye

Pavel Kouřil

Pierre Joye

Yasuo Ohgaki

Tony Marston

Stas Malyshev

Michael Wallner

Tony Marston

Tony Marston

Julien Pauli