[whatwg] Revised Plan for Server-sent DOM events
Anne van Kesteren
annevk at opera.com
Mon Jan 7 02:30:29 PST 2008
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
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
More information about the whatwg