|[Pre-Draft] HTTP Message Proposal||Michael Dowling||1/8/14 1:42 PM|
I formally propose that the FIG begins the process of creating an HTTP message proposal. This has been previously suggested, but not pursued formally until now.
Based on the bylaws, I must first announce this as a pre-draft to see if others are interested in an HTTP message proposal (see https://github.com/php-fig/fig-standards/blob/master/bylaws/004-psr-workflow.md#21-pre-draft).
Here is the proposal that I have put together: https://github.com/php-fig/fig-standards/pull/244
A team has been selected:
- Editor: Michael Dowling
- Coordinator/Sponsor: Phil Sturgeon
- Sponsor: Beau Simensen
- Contributor: Chris Wilkinson (some work is derived from his original proposal)
Please note: This email is meant only to gauge interest in such a proposal and not to determine if everyone agrees with the standard being presented.
|Re: [Pre-Draft] HTTP Message Proposal||Phil Sturgeon||1/8/14 1:48 PM|
Further information on why this proposal makes for a strong start.
1. Michael Dowling is the creator of Guzzle, so has a good base of experience with the many problems HTTP messages could bring up
2. It implements much of the advice from previous iterations, meaning we can theoretically get going quicker.
3. It avoids the "HTTP Client" stuff, just giving us the absolute basics of HTTP messaging.
If you gave specific issues then at this stage they can be taken up with Michael offline, via email, on GitHub, wherever but please leave them out of here. This is just a formality at this point, and we don't all need to agree on specific content.
If nobody has any major concerns then I'll put this in for a Entrance Vote a week from now. :)
|Re: [Pre-Draft] HTTP Message Proposal||Larry Garfield||1/8/14 4:49 PM|
Color me very interested!
Out of curiosity, what happened to the idea of having a separate URI
spec that this builds on? Did that get folded back in, or punted as
over-engineering? (I'm still in favor either way, I'm just wondering
what happened to that.)
--Larry Garfield, Drupal
|Re: [Pre-Draft] HTTP Message Proposal||Michael Dowling||1/8/14 5:28 PM|
While a URI spec would be interesting, I don't think it's required for the HTTP message PSR. For example, an HTTP message proposal can allow anything that can be cast to a string to be provided as the URL. This is what I present in the HTTP message PSR I've linked to.
|Re: [Pre-Draft] HTTP Message Proposal||Phil Sturgeon||1/8/14 6:30 PM|
I was never really sure what a URI spec was supposed to be, and as Michael says a URI is just a string, so in regards to this PSR it shouldn't really matter.
Also, generally trying to make PSRs not rely on other PSRs seems to be a good idea.
|Re: [Pre-Draft] HTTP Message Proposal||Jason Judge||1/10/14 2:41 AM|
Yes, it is a string ultimately, when passed out to the web to make a request for a resource. However, when dealing with web services, the URI needs to be constructed, and that construction needs data to define it and rules/templates to follow. Depending on the scope of a HTTP spec, the construction of URIs may be relevant. A library such as Guzzle will be constructing URIs to access resources, but the part of that library that just deals with the HTTP communication will just be using the URL strings it is given from higher up.
In this case the scope is pretty much limited to the HTTP messaging part, so the URI is just a string. I can see how people may want to widen that to cover more of their use-cases, but scope creep has IMO always been the enemy of the PSR creation process. So yeah, it's just a string. Generating the string is what the URI spec would be about :-)
|Re: [Pre-Draft] HTTP Message Proposal||Kris Wallsmith||1/10/14 1:16 PM|
I fully support this initiative and agree with the reasons behind focusing only on messages. Thanks for taking the lead, Michael!
|Re: [Pre-Draft] HTTP Message Proposal||Kris Wallsmith||1/10/14 1:53 PM|
Also, I'd be happy to help as a sponsor if needed.
|Re: [Pre-Draft] HTTP Message Proposal||Larry Garfield||1/12/14 9:51 AM|
For the time being, we can probably get away with "string or an object that implements __toString", which would let us or someone else later implement URI objects if needed without any hard dependencies. Drupal is currently debating a URI object for our own use, although more coupled to the Symfony routing system we have, so there is demand for it. But I'm fine with leaving it out of scope for now as it's trivially easy to introduce later without any new PSR dependencies.
I think we have general agreement that a vote to bring an HTTP message proposal into the pipeline as PSR-7 would pass. I'd also be happy to help make this happen.
|Re: [Pre-Draft] HTTP Message Proposal||Phil Sturgeon||1/12/14 11:13 AM|
Great. Thanks for the vote of confidence Larry!
It's only been two days but this was purely a formality. There is no time requirement, and as we've had enough time for people to see two email digests with subject, people don't have a huge amount of ability to complain.
|Re: [Pre-Draft] HTTP Message Proposal||Beau Simensen||1/13/14 10:26 AM|
I haven't had a chance to weigh in on this yet but as I am listed as a sponsor I think it should be obvious I'm interested in seeing this topic explored. Thanks for picking this up, Michael, and thanks to everyone whose work this is based on. I know we've been batting this idea around in various forms for a very long time. It will be great to see where this goes once we have it added to the PSR workflow.
|Re: [Pre-Draft] HTTP Message Proposal||Robert Hafner||1/18/14 5:48 PM|
This all seems very interesting, but I'm unclear on what exactly would be standardized by this and how it'll help with interoperability. This isn't to say that I don't think it'll help, just that I literally have not seen this explained anywhere. Is there any chance someone can comment on that a little bit, and speak to what the goals here would be?
|Re: [Pre-Draft] HTTP Message Proposal||Phil Sturgeon||1/20/14 9:23 AM|
HTTP has been discussed here several times which I guess could be a reason why this time the introduction was a little short. That is my fault, I should make things more clear.
A "HTTP" PSR has been on the cards for a really long time, but most felt that it was too much of a challenge to tackle in one go. Just like logging, people were fed up with writing adapter classes for interacting with multiple types of logger, so defining an interface helped people cut that down drastically.
So a HTTP Client PSR seemed a logic move, letting packages like Geocoder avoid writing adapters for Zend, Buzz, Guzzle, Requests, etc.
A HTTP Client however did seem like a lot of work to dive straight into, as there were SO MANY factors. To easy this somewhat, a HTTP Message PSR was proposed to tackle the Request/Response stuff first. By defining these, a client would much later be easier to work with. Some systems could easily utilize this PSR to cut their code down, as HttpKernel, Joomla, Drupal, Kohana, Guzzle, Buzz, etc all have similar-by-different Req/Resp classes and that is a little silly.
There were about 5 alternatives happening and nobody had the time/effort/energy to find one and run with it - especially before we had a workflow for handling that stuff. But now Michael is on the case, we lookl like we have a team who is willing and able to get the job done. Hopefully when complete we can keep on trucking with get the HTTP Client lib on the go, which is considerably more useful for the average developer - much like your cache PSR.
|Re: [Pre-Draft] HTTP Message Proposal||Phil Sturgeon||1/21/14 10:45 PM|
Some of that made no sense. I think I must have edited it a few times and not done a very good job. I definitely don't think that "To easy this somewhat" is a valid sentence.
Regardless, it seems like most folks are content with this entering as a PSR, and the vote is going well. If anyone has questions then get in touch, otherwise we can start thinking about what needs to be done in draft.