[whatwg] Revised Plan for Server-sent DOM events

[Stewart Brodie]

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.
> 
> The major concerns I've heard about section 6.2 include:
> 
> - Unnecessary dependency on DOM Events

Why is this a problem?  It's a facility to cause DOM events to be
dispatched.


> - Redundancy with already existing techniques, especially XMLHttpRequest

There are quite a lot of additional behavioural requirements for server-sent
DOM events that do noy apply to XMLHttpRequest, specifically the automatic
binding to event-source elements, plus the automatic reconnection
algorithms.


> - Complicated parsing of event fields

The major problem is determining the type information for the fields of
arbitrary events.  In the end, I gave up on this and simply stuffed the data
into the JS Event objects as strings and allowed the interpreter to worry
about the numeric conversions, provided that the field name was validated.  


> - Inability to support cross-domain events (without the as-of-yet  
> unimplemented and untested Access-Control HTTP header mechanism)

I don't see this as a particular problem - other facilities are waiting for
that to be done too.  I'd rather use the same mechanism everywhere.


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

This might be alleviated somewhat, but not resolved by moving the
connections to other servers.  Does anybody implement the 2 connection limit
in desktop browsers anyway?  Last time I actually tested, most of them
appeared to be using at least 4.



> 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  

... that you know of ...

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

I have an implementation - it does precisely that, as I mention above.


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

Not really - it's still possible for applications to cause problems by
trying to create 3 event streams.  My implementation permits 2 event streams
to any given host in addition to any used for "normal" accesses.
Additionally, we have a class of privileged applications for which all the
usual restrictions (cross-domain scripting, same origin checks, connection
limit, etc.) are relaxed, precisely because we need sometimes require things
like cross-domain XHRs in our embedded environments.


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

Removing the requirement to support anything other than MessageEvent class
of events would certainly be a tremendous simplification.  I'm not sure
whether or not it is a good idea - it would leave us needing to perform all
sorts of string parsing in our JS if we wanted to issue other types of
event.  In fact, if this simplification were to be made, I'd probably have
to retain this ability for compatibility with our existing applications.


-- 
Stewart Brodie
Software Engineer
ANT Software Limited