- From: Kornel Lesinski <kornel@geekhood.net>
- Date: Wed, 18 Feb 2009 10:49:08 +0000
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)
Received on Wednesday, 18 February 2009 02:49:08 UTC