[web-devel] Proposed change to WAI: responseRaw

[Jasper Van der Jeugt]

Great! I always considered `settingsIntercept` a little ad-hoc.  This
sounds like a nice generalisation.

Peace,
Jasper

On Wed, Mar 05, 2014 at 06:54:53PM +0200, Michael Snoyman wrote:
> I've just tested out a new feature in WAI, which is available for testing
> on the raw-response branch[1]. Here's a summary of the change itself and
> its purpose. If there are no objections, I'm planning on releasing this as
> WAI 2.1.
> 
> The goal is to have better support for WebSockets. WAI 2.0 and earlier are
> based purely around request/response pairs, without interleaving of reads
> and writes. There is some ambiguity about that interleaving when it comes
> to streaming responses[1], but essentially, WAI does not currently support
> the ability to have bidirectional communications with a client.
> 
> The current wai-websockets package ties into a special settings hook
> provided by Warp (settingsIntercept). While this works, it makes it
> difficult to provide websockets support as a first-class citizen of a web
> framework. It also makes creating a WebSockets-aware HTTP reverse proxy
> more involved and less efficient.
> 
> The proposed change comes down to a single new function in Network.Wai:
> 
> responseRaw
>     :: (C.Source IO B.ByteString -> C.Sink B.ByteString IO () -> IO ())
>     -> Response
>     -> Response
> 
> This would including a corresponding addition of a ResponseRaw constructor
> to Resonse. The idea is that the application would provide a function which
> takes a Source of bytes from the client, a Sink for sending bytes to the
> client, and the web server would provide that source/sink to the
> application. Since not all backends will support responseRaw (e.g., CGI),
> there is a requirement for a backup Response to be provided, which will be
> used in those cases.
> 
> This is a very minor breaking change to the existing API. Only code which
> explicitly pattern matches on Response constructors will be affected, and
> even there the necessary changes are trivial (see the changes on the
> raw-response branch).
> 
> Are there any objections to this change, or recommendations for ways to
> make it better?
> 
> Michael
> 
> [1] And in fact, I first tried implementing this change purely using the
> existing streaming response interface. However, after attempting it, it
> felt like too much of a hack, so I went for the responseRaw approach
> instead.

> _______________________________________________
> web-devel mailing list
> web-devel at haskell.org
> http://www.haskell.org/mailman/listinfo/web-devel