[whatwg] <eventsource>/RemoteEventSource wierdness
ian at hixie.ch
Thu Feb 26 00:34:46 PST 2009
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 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
> 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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg