[RFC] [VOTE] pecl_http

Hi Levi,

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

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.

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

Hey everyone,

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/

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

Hi,

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.

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

<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

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

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

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

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

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

"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