Re: [whatwg] eventsource/RemoteEventSource wierdness
On Mon, 2 Mar 2009, Michael Nordman wrote: One key feature that IMHO is needed in this area is sharing of events between pages/windows A cross-page event broadcast facility is co-mingled with the DOMStorage corner of the spec (see 5.11.1.5 The storage event). It may be nice to carve that out as a separate facility that can be utilized in the absence of storage. Shared workers are the expected way to do this at this point. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] eventsource/RemoteEventSource wierdness
One key feature that IMHO is needed in this area is sharing of events between pages/windows A cross-page event broadcast facility is co-mingled with the DOMStorage corner of the spec (see 5.11.1.5 The storage event). It may be nice to carve that out as a separate facility that can be utilized in the absence of storage.
Re: [whatwg] eventsource/RemoteEventSource wierdness
On Tue, 03 Mar 2009 05:49:12 +0900, Michael Nordman micha...@google.com wrote: A cross-page event broadcast facility is co-mingled with the DOMStorage corner of the spec (see 5.11.1.5 The storage event). It may be nice to carve that out as a separate facility that can be utilized in the absence of storage. Take a look at postMessage() ;-) (It ships in all browsers.) -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] eventsource/RemoteEventSource wierdness
On Mon, Mar 2, 2009 at 4:48 PM, Anne van Kesteren ann...@opera.com wrote: On Tue, 03 Mar 2009 05:49:12 +0900, Michael Nordman micha...@google.com wrote: A cross-page event broadcast facility is co-mingled with the DOMStorage corner of the spec (see 5.11.1.5 The storage event). It may be nice to carve that out as a separate facility that can be utilized in the absence of storage. Take a look at postMessage() ;-) (It ships in all browsers.) I was under the impression that postMessage() was directed at a particular window (or context). Does postMessage have a broadcast capability? Storage events have a broadcast'ish nature to them. Multiple windows (or contexts) will receive storage events as changes are made to the 'storage' area. The sender does not need to know anything about the receivers or of their existence. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] eventsource/RemoteEventSource wierdness
On Tue, 03 Mar 2009 10:06:30 +0900, Michael Nordman micha...@google.com wrote: I was under the impression that postMessage() was directed at a particular window (or context). Does postMessage have a broadcast capability? Storage events have a broadcast'ish nature to them. Multiple windows (or contexts) will receive storage events as changes are made to the 'storage' area. The sender does not need to know anything about the receivers or of their existence. Sorry, I misunderstood what you meant. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] eventsource/RemoteEventSource wierdness
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. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] eventsource/RemoteEventSource wierdness
On 17.2.09 22:53, Jonas Sicking wrote: This could also replace the IMHO awkwardeventsource 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 seem to recall reading once that it's not the case that the only way you can use the API is through script -- sort of. At one time I believe the intent was that an onmessage attribute on body would allow you to have handlers without needing to run script to set them. You would of course still need script to execute for the handler to run. That said, I don't think that reason is at all compelling. As far as any list of features to cut (spin into other specifications) goes, I would rate this one fairly high on it, particularly if the element API were scrapped in favor of a pure-script API. There are interactions with the current task-queueing mechanism in HTML5, to be sure, but eventsource is mostly a consumer of those mechanisms, not a contributory component of it. I don't think eventsource's removal would affect the continuing evolution of the queueing mechanism in any meaningful way. Jeff
Re: [whatwg] eventsource/RemoteEventSource wierdness
On Thu, Feb 19, 2009 at 3:10 AM, Jeff Walden jwalden+wha...@mit.edu wrote: On 17.2.09 22:53, Jonas Sicking wrote: This could also replace the IMHO awkwardeventsource 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 seem to recall reading once that it's not the case that the only way you can use the API is through script -- sort of. At one time I believe the intent was that an onmessage attribute on body would allow you to have handlers without needing to run script to set them. You would of course still need script to execute for the handler to run. Exactly, it's the fact that you ultimately always have to forward to a script to handle the event that I was referring to. This isn't 100% true though. As I understand it, the idea is to allow support for firing other event types than 'message', at which point I *think* you could do things like trigger SMIL animations and run XForms actions without resorting to javascript. However neither of these things are practically supported by the spec now, so I don't think that's an argument for keeping the current design. And it still doesn't explain why you'd want addEventSource on XMLHttpRequest, WebSocket or Window. / Jonas
[whatwg] eventsource/RemoteEventSource wierdness
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. What are the use cases for this?
I.e. why do we need XMLHttpRequest.addEventSource,
ProcessingInstruction.addEventSource, WebSocket.addEventSource,
Window.addEventSource etc. Are there use cases for every one of these?
And if there are, why not DOMImplementation.addEventSource,
JSON.addEventSource etc?
It seems like we're adding functionality to a bunch of unrelated
objects, and the functionality we're adding is largely unrelated to
most of them.
If we really need a RemoteEventTarget API at all (more on this later),
why not simply have something like:
[Constructor(in DOMString url)]
interface RemoteEventTarget : EventTarget {
void addEventSource(in DOMString src);
void removeEventSource(in DOMString src);
};
This would result in code like:
x = new RemoteEventTarget('/events/ticker');
x.addEventListener('message', tickerHandlerFunction, false);
We could even drop the addEventSource/removeEventSource API. If you're
not interested in receiving more events, remove the event-handler and
drop the object on the floor.
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. In this case it seems like we're
adding a full element to avoid a single line on JS code that the above
API would requre:
eventsource src=/events/ticker onmessage=ticker(event)
vs.
x = new RemoteEventTarget('/events/ticker');
x.addEventListener('message', ticker, false);
Additionally the eventsource element as currently defined actually
suffers from a potential security problem. Imagine a page that adds a
couple of eventsource element and registers a capturing event
listener on the window to catch events from several eventsources.
This event listener has to listen to 'message' events.
However, any site can embed this page in an iframe and cause
'message' events to be fired at this event handler by calling
postMessage. It is unlikely that this handler will first check the
'origin' property of the message event since the page was created to
listen to same-site event sources.
This exact problem, though at a somewhat larger scale, exists with
allowing addEventSource exist on window objects, since then the event
listener doesn't have to be capturing.
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.
/ Jonas
