Proposed change to WAI: responseRaw
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.
---------- Forwarded message ----------
From: Michael Snoyman
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@haskell.org http://www.haskell.org/mailman/listinfo/web-devel
participants (3)
-
Greg Weber -
Jasper Van der Jeugt -
Michael Snoyman