…s not seem to have any effect when client interrupts the connection, so in that aspect, nothing has changed (sadly).
…ranports are more conduit based).
…ion. Updated the WebSockets code. The ability of closing the session from withing the Application causes some problems with the WebSocket implementation, at the moment, if the session is closed by the CloseSession message, we end up in an endless loop, the reason is that the foreverReceive never ends. We could have the forverSend and foreverReceive communicate with each other using the sessionStatus MVar, but I'm worried since it cause problem if we receive much more than we send (since the threads would have to wait for each other) and it could even cause dead locks (not to mention I would have to get rid of the direct recursion which I intended anyway).
…k) is of the type H.Request -> Server H.Response. The server implementation thus has to implement function for converting between the request and response types and a way to run ResourceT IO in its monad. Implementation for Wai is included.
…types independent of Wai.
…need them after I integrate WebSockets.
…uite regarding XHR Polling now pass). Made some settings application-wise instead of server-wise.
…per response headers, decode incoming JSON, more importantly add timeouts and heartbeats, but most importatnly -- make the code prettier (adding a Server monad containing environment, settings, Request wrapper containing (Maybe) Application, Session, SessionID, etc. might help a bit, but there are some disgustingly long lines in Transports.XHR)
…sport/XHR.hs is very, very ugly and I can not find a way to make it prettier
…parated response and header helpers into their own module.
…e a circular dependency)