[whatwg] <eventsource>/RemoteEventSource wierdness

[Kornel Lesinski]

On 18 Feb 2009, at 06:53, Jonas Sicking wrote:

> This could also replace the IMHO awkward <eventsource> element. I
> don't understand the value of having this element at all. It seems to
> me that if the only way you can use an API is through script, then
> making the API into an element is adding extra complexity to the HTML
> language for little to no gain.

I agree with that one. I don't see any reason why sources need to be  
declared in HTML (sources are site-specific and useful only with JS  
enabled, so non-JS clients, bots, etc. don't need to know about them).

> Finally, I do question the need for this API at all.


I like the concept and find it useful. I think existence of Comet[1]  
is a proof that such feature is desired, even without support for SMS.

Implementation of Comet via XHR is tricky, especially robust error  
handling is difficult. JS libraries can't have best implementation of  
event streams, because JS doesn't have enough control over network  
connections (e.g. can't bypass proxy if it doesn't handle long-lived  
connections well). Native browser implementations can excel here.

One key feature that IMHO is needed in this area is sharing of events  
between pages/windows - e.g. page with stock ticker doesn't need  
separate stream for every page in every window. One permanent  
connection shared between windows and kept alive between page reloads  
would be sufficient, and would save both client and server resources  
and wouldn't have problems with HTTP/1.1 connections limit.

1. I think that such feature is needed and event source should be kept  
in some form.
2. I wouldn't mind if event source API was redesigned, made JS-only  
(without DOM), moved to separate specification or merged with XHR/web  
sockets.
3. Connection sharing is needed to make it a killer feature.

-- 
regards, Kornel

[1] http://en.wikipedia.org/wiki/Comet_(programming)