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
