Expressive without Diactoros

Transferring discussion of the issue I opened here, what would it take to disassociate Zend Expressive from Diactoros? Personally I find it a little weird to not be depending on psr/http-message-implementation.

In my application, we make heavy use of Guzzle and would prefer to use it as the only PSR-7 implementation.

I think only the Response can be swapped easily.

  • The Emitter is not available in Guzzle.
  • Guzzle doesn’t have the specific response types.
  • The ServerRequest classes are not compatible.

Personally I find it a little weird to not be depending on psr/http-message-implementation

Isn’t that exactly what Diactoros is for? It does the same thing as Guzzle/PSR7. Just a bit different and it has helper classes for Guzzle whereas Diactoros has extra classes for Expressive.

  • (SAPI) Emitter can be replaced with response-sender.
  • Specific response types should be moved to a separate package that acts as a Response factory. It doesn’t make sense to have them in a PSR-7 implementation.
  • Guzzle’s ServerRequest is (as far as I can tell) comparable with Diactoros. I’ve been using it for a couple of months.

The purpose of PSRs is that it allows dependence on any implementation. A framework that requires PSR-7 should depend on the abstraction not the implementation.

While I agree with you, I don’t think there are lots of people who use guzzle as psr7 implementation with expressive. For the record, Diactoros was the first implementation. And many of the people who use guzzle may be using guzzle as a library inside expressive :slight_smile: . And may be in the future probably slim/http ( 4.x ) will also will be coming.

Honestly, the main reason we’re still tied to Diactoros for the implementation is due to waiting for the dust to settle around http-interop/http-factory (aka PSR-17). There’s still a fair amount of discussion occurring around stream factories in particular, which, when you consider that most responses need to populate a message body, which means populating a stream, means we cannot yet adopt it. Once the dust has settled and the API seems stable, we can look at updating the code base to use those factories, which will de-couple us from specific PSR-7 implementations.

For the record, I’m all for this; just waiting until we get the working group in place and can do a final acceptance vote as a WG. :smile:

2 Likes