hunchentoot serving manifest files, ie. .appcache files.

[Ron Garret]

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 at 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 at 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 at 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.
>>> 
>> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20140301/e0e0b008/attachment.sig>