Contribute to http-interop

[shadowhand]

PSR-17 is an upcoming proposal that will standardize HTTP Message factories. The work of defining the actual interfaces is happening right now in @http-interop http-factory repository.

Can we work together to make http-interop/http-factory the standard moving forward?

[shadowhand]

I know that I have expressed doubt about HTTPlug in the past and I do still have reservations. That said, the foundational work around having a set of standard PSR-7 factories is extremely important for the adoption of PSR-7 and benefits the entire PHP ecosystem.

Here's to looking forward instead of back! 🍻

[Nyholm]

We sure had some discussions which have shocked me because I know we want to achieve the same goal. I also share your concern about the importance of the PSR-7 factories.

I'm happy that you reached out and asked this question. And of course, let's work together 🍻

[sagikazarmark]

Hi Woody,

Thanks for reaching out, I really look forward to work on this. I've already gone through the current interfaces. If I saw correctly, the inheritance has been removed, which is great IMO.

As far as I can see Diactoros is the only implementation, so I would like to support this project by the following:

1. Create an unofficial Guzzle implementation if I can't find any (sane one)
2. Create a bridge between our factories, so eventually we can deprecate our vendor factories (Diactoros and Guzzle) and use "official" ones without breaking BC in our packages
3. Once this proposal reaches standard phase, deprecate this factory package and recommend PSR-17

At least this is the roadmap I can see regarding PHP HTTP packages.

As for actual contribution: I will look at the interfaces more closely. @dbu and I will have a workshop @ Web Summer Camp where we can advocate PSR-17. Apart from that, I think the most useful contribution at this stage is to use the interfaces and find any possible problems. Given the similarities between our interfaces and the proposed PSR-17 ones, I wouldn't count on too many. In fact, I would like to see this the fastest standard to be accepted.

About personal things: this is not the FIG. Although you (and me, everyone) got used to the political and personal issues affecting work within the FIG, I really think this is NOT the way professional work should happen. As long as the personal or any other issues does not affect the ongoing work (as I expressed on the thread you asked Paul to step down), I don't really care what other conflicts/disagreements we have.

[dbu]

when we started with the message factory interfaces (and the client interface, as well) we all agreed that both things would best fit into a PSR as they are meant to be a general standard. and a general standard by a standardization group is much better than a standard by an ad-hoc group. i agree with @sagikazarmark and hope to eventually deprecate the php-http/message-factory interfaces and point people to PSR-17.

[ramsey]

Now that PSR-17 has been ratified, would you be open to a pull request that has each of the interfaces here extending the PSR interfaces? I think this would require a major version bump, since there are a few differences that would provide BC breaks (i.e. difference in signature of Psr\Http\Message\UriFactoryInterface::createUri() and additional required methods in Psr\Http\Message\StreamFactoryInterface).

If you're open to it, I can put together a PR.

(Background: I just ran into a problem trying to use UriFactoryDiscovery::find() with a method that expects a Psr\Http\Message\UriFactoryInterface object. Unfortunately, I can't use the discovery method because none of the classes in Http\Message\UriFactory implement the PSR interface.)

[shadowhand]

@ramsey you might be interested in http-interop/http-factory-discovery.

[ramsey]

@shadowhand Oh, nice! I wasn't aware of the http-interop project. Thanks!

[shadowhand]

@ramsey it's where the PSR-17 interfaces were prototyped. We're keeping it around to provide utility packages for PSR-15/17.

[sagikazarmark]

I think instead of implementing the interface this package should be deprecated instead together with the implementations (where it makes sense).

I would assume (or kinda hope) that the PSR-17 implementations will move next to the PSR-7 implementations (Guzzle, Diactoros and Nyholm PSR-7 being the three major ones).

PSR-18 is also going to be accepted soon being a big change for the PHP-HTTP ecosystem, so if it brings breaking changes (we hope it won't) then switching to PSR-17 in the same step will probably happen as well.