[whatwg] <eventsource>/RemoteEventSource wierdness

[Jonas Sicking]

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 <eventsource>s.
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