On Sun, Sep 25, 2011 at 5:46 PM, Jasper Van der Jeugt
Hello all,
I have been working on a WebSocket [1] library lately, which you can find here [2]. It's getting to the point at which I want to release it on Hackage. However, there is one thing remaining before the library will be really useful for applications: integration.
I would like to provide integration with Happstack, Snap and Yesod -- this is why I have built the library around the enumerator package [3]. It would be awesome if frameworks could more or less agree on a way in which an HTTP connection can be "transformed" to a WebSocket.
That way, I will be able to provide packages such as `websockets-warp`, `websockets-snap` etc.
Currently, the "entry point" of the websockets library is the following function:
runWebSockets :: WebSockets a -> Enumerator ByteString IO a -> Iteratee ByteString IO () -> Iteratee ByteString IO a
Where the first argument is the user-supplied code in the `WebSockets` monad (needs to keep a bit of state etc.), the second argument is an enumerator which the library can use to read from the socket, and the last argument is an iteratee with which the library can write to the socket.
A web server then needs to provide some way to get this enumerator/iteratee pair, and hand it over to the library (currently, this is lacking). Some more details apply, e.g. the web server shouldn't kill the websocket handler as fast as regular HTTP connections.
Is this proposal somewhat agreeable? I'm open to any feedback.
[1]: http://en.wikipedia.org/wiki/WebSocket [2]: http://github.com/jaspervdj/websockets [3]: http://hackage.haskell.org/package/enumerator
Cheers, Jasper
_______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel
I really like this approach. We had a discussion in #yesod not too long ago that essentially came to the same idea of having a plugin to add WebSocket support at the server level. I like even more that this would work for multiple servers. I think my main question is: why take an enumerator? Should the function just run as an iteratee? I know that will make it much more amenable to integration with Warp. All of Warp's internal processing lives inside an Iteratee, so we can't really extract an Enumerator from there. This is already how Warp handles the request body (the application lives in an Iteratee), so I think the approach is sound. I'll be happy to play around with Warp integration. Michael