[whatwg] Revised Plan for Server-sent DOM events

[Anne van Kesteren]

On Sat, 05 Jan 2008 07:51:29 +0100, Henry Mason <hmason at mac.com> wrote:
> There's recently been some talk about completely removing HTML 5 section  
> 6.2, "Server-sent DOM events". I propose that rather than remove, we  
> revise.

I agree that we should keep it.


> - Continued problems of the 2 connection limit on HTTP server scalability

Is there any realistic solution to this other than to use separate domains  
and have cross-domain working?


> I propose that we remove support for non-message events; that is, allow  
> only events with MessageEvent interface. This will make implementations  
> easier, as UAs will only need to parse the "Bubbles", "Cancelable", and  
> "data" fields.

Opera also supports the "Event" and "Target" fields. I think we'd be fine  
if the latter is removed, but the former is really useful as you can then  
have separate handlers to deal with the incoming data. (That they all  
implement the same MessageEvent interface is fine.)


> The critically cool part, however, is that since MessageEvents store  
> their domain and URI origin, it will be safe to allow for cross-domain  
> messaging through this server-sent events. Section 6.1 already uses this  
> system for this very purpose. Opera has already implemented it and it  
> has been in WebKit's trunk for about a week.

WebKit is implementing cross-document messaging? Cool!


> The removal of the same-origin restriction actually makes this interface  
> dramatically more useful for developers. It provides a capability  
> (messaging with a foreign host) which is not already available to  
> XMLHttpRequest-using applications. It also makes it easier web  
> developers to more easily offload the long-running HTTP connections  
> needed for event streams to separate servers. This aides in application  
> scalability and circumvents potential problems with the 2 HTTP  
> connection limit.
>
> This change would make server-sent events easier to implement for both  
> UA implementers and web application developers and would make the  
> developers more likely to use it.

This does have the disadvantage that you always share your data with  
everyone where you can restrict that with Access Control. Especially for  
authenticated services this might be problematic.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>