PSR-7?

[Crell]

The Message component interfaces looks an awful lot like PSR-7's interfaces. I'm sure that's not coincidental. 😄 Is there a reason to not just use the PSR-7 interfaces? Or is it just that no one has gotten around to switching it over yet?

[mtymek]

See #2.
I was working on a bridge library for PSR-7 integration.
It works nicely in "Hello World" application, but real wold apps are more complex. For instance, Router middleware works as expected, but anything that touches database or files is blocking your app. So it is not really possible to mix PSR-7 and Icicle code when it comes to real-life use cases.
I will follow up on this when I'll have more time, to at least publish my "Hello, World" app.

[Crell]

Why is PSR-7 problematic for async? Supporting non-CGI use cases was one of the key reasons we made the interfaces immutable.

Diactoros may be problematic for async. That wouldn't surprise me at all, actually, since it was optimized for CGI-server environments (like Zend, Symfony, Drupal, etc.) But Guzzle, for instance, has their own PSR-7 implementation and they do some async things as well, as an HTTP client. It may just take more boilerplate repetition, or factoring some of the sharable boilerplate out of Dicatoros (which I'd love to see happen, actually; there's lots of traits that could be hosted by FIG and shared by everyone).

[trowski]

Guzzle is able to perform multiple requests simultaneously and consume the results as they are available, but once a requests completes, reading from that request is synchronous. Guzzle is a pseudo-asynchronous way of performing HTTP requests. Guzzle uses curl_multi_select() to poll active cURL requests for completion. This generally is not compatible with other async code, as blocking on curl_multi_select() would block less specific methods of polling streams such as stream_select() (this is the method used by the event loop in Icicle that does not require an extension, see here).

PSR-7 works for Guzzle because operations on streams of a completed request may be synchronous. However, while blocking on a stream read, no other completed requests can be handled.

Icicle is designed to be asynchronous (non-blocking) at all times. It is imperative that nothing blocks the main thread. @CoderStephen and I are working on a Concurrency package that will allow an Icicle process to spawn threads or fork to perform blocking tasks.

I'm closing this issue in favor of #2 so the conversation does not become fragmented.