[whatwg] Revised Plan for Server-sent DOM events

[Henry Mason]

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.

The major concerns I've heard about section 6.2 include:

- Unnecessary dependency on DOM Events
- Redundancy with already existing techniques, especially XMLHttpRequest
- Complicated parsing of event fields
- Inability to support cross-domain events (without the as-of-yet  
unimplemented and untested Access-Control HTTP header mechanism)
- Continued problems of the 2 connection limit on HTTP server  
scalability

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. The only existing implementation  
(Opera) seems to only use the message event part of the interface  
anyway. In the few rare instances where general DOM Event bindings  
are needed, JavaScript parsing of the data field of the message  
events could be used.

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

-Henry