Personally I much prefer server-side events (SSE). It’s a lot simpler than websockets. On the client side all you do is:
var source=new EventSource(URL); source.onmessage=function(event) { do_something_with(event.data); }
and on the server arrange for URL to have a content-type header of text/event-stream, and send lines of the form:
data: [your data] <newline><newline>
to the stream you obtain from calling (ht:send-headers). (Note: this stream is a binary stream so you have to encode strings to bytes and use write-sequence, or wrap it in a flexi-stream, but that’s the only complication.)
rg
On Feb 28, 2014, at 1:40 PM, Left Right olegsivokon@gmail.com wrote:
Not exactly answering your question, but if you are looking for push functionality in browser, then WebSockets might be a better option. The reason server-sent events exist is by and large due to the handicapped nature of most popular web-development stack in use today, such as PHP interpreter that has to be started on every connection by an HTTP server, such as Apache httpd or ngnx. This means that traditional setup works in a stateless manner. This is unlike, say, most Java HTTP servers (Tomcat, JBoss etc) or Python (Twisted, Tornado), where the setup is normally stateful, meaning that you wouldn't need to restart the interpreter upon each request, instead, your server would persist the state until it is shut down. Hunchentoot belongs to the later category.
Now, because it's not really possible to persist a PHP session across multiple requests, a technique first known as long polling appeared. The operating principle was that the server, in response to an HTTP request would not close the connection immediately, instead it would keep sending the information, whenever the application state at the server would demand it. The receiving side (the browser) would listen to updates on this connection and interpret them as "pushes". Event stream is a refinement of this scheme.
WebSockets, on the other hand, are plain TCP sockets, which means that they don't require HTTP wrapping to function. I haven't had much experience with JavaScript WebSockets, but I used their analogy in Flash quite a bit. It was a relief not to depend on the bizarre rules of HTTP protocol and its encodings, headers and so on. So I would expect the same to hold for WebSockets.
Best,
Oleg
On Fri, Feb 28, 2014 at 11:09 PM, Faruk S. Can farukscan@gmail.com wrote:
I have read in w3schools about usage of server sent events in html5. it says:
Set the "Content-Type" header to "text/event-stream" Specify that the page should not cache Output the data to send (Always start with "data: ")
that is in echo line in php code as echo "data: The server time is: {$time}\n\n";
Flush the output data back to the web page
http://www.w3schools.com/html/html5_serversentevents.asp examples here are in php for server side. i am using hunchentoot on common lisp.
On Fri, Feb 28, 2014 at 10:27 PM, Faruk S. Can farukscan@gmail.com wrote:
I have another question about hunchentoot. Is it possible to use server sent events with hunchentoot, like other html5 improvements mentioned in w3schools-html5 such as app cache, local storage, session storage? as that one related to and depend on the server side support.