@Ron Garret I didn't mean HT own log, but even then locking isn't the best solution always: for example, I don't know what bordeaux-threads does when a thread holding a lock dies, does it release it? What if it depends on Lisp implementation? Maybe a lock-free queue would be a better option for log? - I don't know. Anyways, my point was that these would be non-trivial questions to answer, and while it is easy to come up with a simple SSE implementation, a real-world implementation might be a lot more difficult to master. Environments like PHP running as Apache httpd module don't have this problem, because they are single threaded, so, there it's a good (and, practically, only) choice. But it is good in a very limited sense... as it suffers from high congestion (something that concurrent execution is meant to address).
A side note: SSE doesn't work (yet?) in Internet Explorer :) Well, I guess OP was already aware of it.
@Hans Hübner
I haven't tried it, but this is the quote from the front page of http://www.websocket.org/aboutwebsocket.html
A WebSocket detects the presence of a proxy server and automatically sets up a tunnel to pass through the proxy. The tunnel is established by issuing an HTTP CONNECT statement to the proxy server, which requests for the proxy server to open a TCP/IP connection to a specific host and port. Once the tunnel is set up, communication can flow unimpeded through the proxy. Since HTTP/S works in a similar fashion, secure WebSockets over SSL can leverage the same HTTP CONNECT technique. [...]
I'm not sure whether SSE can do the same and how well does this address the problem of proxies in general. From my experience using Flash sockets (they don't know how to tunnel over HTTP on their own), there was some obscure extension to HTTP 1.1 which allowed one to emulate simple TCP over HTTP :) I think that Adobe RTMP uses something like that as a fallback. As we actually had to use it (the product was an RP game, where many players were using computers behind NAT or some sort of corporative proxies, firewalls etc), we found that emulating TCP over HTTP in that way suited us better then other options we considered.
On Sun, Mar 2, 2014 at 8:10 AM, Hans Hübner hans.huebner@gmail.com wrote:
While SSE wins over WebSockets in terms of simplicity, it should be noted that intermediate http proxies may not deal with the protocol in the required ways (i.e. the proxy may not forward the request until the whole response has been read). One way around that is to use https, which will implicitly make the proxy forward the connection directly to the origin server, but may be forbidden by some proxies altogether. WebSockets share the problem, but as they are defined a bit more strictly than SSE, they may see more support in intermediate proxies.
The only universally safe way to push events from a HTTP server to a client is to use (long) polling. Other methods are not advisable if universal availability of the service is desired.
It is unfortunate that there is no maintained WebSockets service that works well with Hunchentoot. There once was Hunchensocket, but it did not receive any love over the last few years and thus requires considerable work to bring it up to date.
-Hans