[whatwg] <eventsource>/RemoteEventSource wierdness

[Ian Hickson]

On Tue, 17 Feb 2009, Jonas Sicking wrote:
>
> So it was brought to my attention that the RemoteEventTarget interface 
> is intended to be implemented on all objects that implement EventTarget. 
> This seems like it's adding a high level of complexity to me.
>
> [...]
>
> Finally, I do question the need for this API at all. Originally it was 
> developed to allow for the messaging channel to be things like SMS or 
> iPhone-push type channels. I.e. in environments where it's very 
> expensive to keep a channel open, but where two-way communication 
> already exists, it would be great to be able to use that existing 
> channel to push messages from the server to the web page.
> 
> However as far as I know no-one has taken the time to make 
> RemoteEventTarget or <eventsource> work with neither SMS or iPhone push. 
> If I'm wrong please do let us know so that this information can be added 
> to the spec.
> 
> So I would recommend the following:
> 1. Remove the whole feature unless someone can show how to make it
> work for SMS or iPhone push.
> 2. If we're really keeping it, remove <eventsource> and the
> requirement that RemoteEventTarget be implemented by all EventTargets.
> Instead create a dedicated object that implements RemoteEventTarget.

On Wed, 18 Feb 2009, Kornel Lesinski wrote:
> 
> 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.

Based on the above feedback and other feedback not quoted above, I've 
redesigned the event source feature to use an object instead of an 
element and a generic API. As always, feedback on this is welcome!

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'