On 1/29/15 6:40 AM, Andrea Faulds wrote:
On 29 Jan 2015, at 12:18, Crypto Compress <cryptocompr...@googlemail.com> wrote:
* Why should we have our own HTTP API and not follow PSR-7?
possible points:
- PHP-FIG propose no implementations; pecl_http does
- native implementations should be faster
I don’t see how that’s relevant: I’m talking here about the API, not the
implementation. Why should PHP’s HTTP API not be PSR-7?
- PHP-FIG focus on frameworks; pecl_http in core is useable without
dependencies by every simple script
Also irrelevant, there’s no reason it couldn’t use PSR-7’s API.
- PSR-7 is a moving target; pecl_http exists for ten years
Fair point.
- PSR-7 can be complementary to pecl_http not the other way around (c code
can't use php code?)
Not necessarily true.
--
Andrea Faulds
http://ajf.me/
In my rainbows and ponies vision of the future, it would go something
like this:
1) PSR-7 is approved. People use it. People love it.
2) Internals makes internal definitions of the interfaces from PSR-7,
renamed to a PHP namespace but otherwise identical. Eg:
\Php\Http\Message
\Php\Http\Request
\Php\Http\Response
\Php\Http\ServerRequest
FIG makes available an alternate set of interfaces that are PSR-7 but
extent the internal ones for type hint compatibility.
Someone (FIG, internals, me?) makes a user-space definition of the new
internals interfaces as a BC layer.
3) Internals improves its userspace stream APIs such that the
StreamInterface from PSR-7 can be retired completely. (It exists almost
entirely as a way to avoid dealing with the PHP-native stream APIs.)
4) Internals adds a function/routine/thing to spawn a ServerRequest that
is equivalent to the user-space code to create a PSR-7 ServerRequest out
of the superglobals. It is, of course, faster than doing in userspace
and also more standard. Internals also adds a "send this response
object to this stream (default stdout)" routine.
5) Everyone switches over to using the Internals-named interfaces and
ServerRequest builder. Because the interface is the same aside from the
name this is about a 5 minute task per project and could be done by a
small shell script.
6) Internals build a simple HTTP client that uses \Php\Http directly.
It's probably not as powerful as Guzzle et al but easily extensible.
Because user-space clients are already using those interfaces, that
makes swapping the new Internals one in instead is a really easy task.
Guzzle et al can convert to being extensions on the core one, all using
the common interfaces.
7) The Ewoks, they dance!
I don't expect it will happen exactly like that, of course, but the
closer we can get to that sort of chain of events the better I think it
will be for everyone.
Note that the interface definition parts are separate from the writing
of the HTTP client. I think it's important to address those two
separately. SRP applies to RFCs just as much as code. :-)
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
