Re: Detailed review of 6.2. Server-sent DOM events

On Wed, 10 Oct 2007 19:59:59 +0100, Mihai Sucan <mihai.sucan@gmail.com>  
wrote:

> "If such a resource completes loading (i.e. the entire HTTP response  
> body is received or the connection itself closes), the user agent should  
> request the event source resource again after a delay of approximately  
> five seconds."
>
> The event source resource polling interval cannot be defined by Web  
> authors. Shouldn't this be configurable somehow? The 5 seconds delays  
> seems completely arbitrary.
>
> After I wrote the above, I looked into the source code of the spec  
> section. It seems Lachlan Hunt also suggested this. Why keep this  
> feature only for the next version?
>
> It seemed as an obvious feature while reading the spec.

In my experience fixed delay isn't a problem. It's just an error recovery  
mechanism. If one's application requires reconnection, server can send  
appropriate event before closing connection, telling client whether it  
should reconnect and when.

However automatic reconnection could use an improvement:
If an application requires to get each and every event only once -- for  
example it's streaming log from the server, line after line, and should  
not display duplicate lines and should not skip any -- in case of network  
failure and automatic reconnection, it's tricky to resume events at the  
right point.

Reliable resuming of event streams requires server to keeping track of  
messages sent to each client, which is costly and only tells how many were  
sent, not how many were sucessfully received. Alternatively server could  
re-send number of messages, but that is wasteful and requires client to  
filter out duplicates.

A solution to this would be for browser to trigger an event when error  
occurs or before it's about to reconnect. This would allow script to  
modify URL of <event-source> to include identifier/timestamp of last  
message it has got, so the server could easily resume the stream from the  
right point.


How about adding XMLHttpRequest-alike interface to <event-stream>? It  
could use readystatechange event to signal connection progress,  
reconnections and network errors. Since it is possible to implement  
<event-stream> using XMLHttpRequest, it might be easy for implementations  
to expose it.

> 3. Why does the specification define "comments" in the stream?
>
> Given it does, why must the UA fire the message event when a comment is  
> sent? There's no use to do so, other than having an event listner which  
> could figure out "hey, something is coming from the server, maybe they  
> are comments".

I agree. If one wants to 'ping' client-side application, he can use an  
event to do so.

-- 
regards, Kornel Lesinski

Received on Wednesday, 10 October 2007 23:33:58 UTC