hunchentoot serving manifest files, ie. .appcache files.

[Ron Garret]

> you may easily run yourself into a situation where two functions try to write to the same output stream


I don’t think so.  The default HT taskmaster on a multi-threaded Lisp spawns a thread per connection and rebinds all the globals.  If it didn’t, then *any* simultaneous connections would have problems, not just SSE connections.  And even on a single-threaded Lisp, subsequent requests would just be blocked until the SSE handler was done.  That would certainly be a problem, but not the one you describe.

rg

On Mar 1, 2014, at 12:58 PM, Left Right <olegsivokon at gmail.com> wrote:

> Don't forget that sockets are concurrent by design: in a simplest
> scenario, you'd allocate a thread per connection. Not a very efficient
> way of dealing with it, but at least it is easy to implement in a way
> that you don't run into deadlocks or other errors caused by multiple
> threads accessing shared state. But if you choose to use server
> events, you would have to be very careful to write re-entrant
> functions to serve the request, which is particularly difficult
> because Hunchentoot relies on a handful of global variables to
> function... you may easily run yourself into a situation where two
> functions try to write to the same output stream, even at the level
> that Unicode byte sequences become interleaved and the receiving side
> would fail with arcane low-level decoding errors (happened to me
> before).
> 
> On Sat, Mar 1, 2014 at 10:04 PM, Ron Garret <ron at flownet.com> wrote:
>> 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/587eaad0/attachment.sig>