On Sat, 05 Jan 2008 07:51:29 +0100, Henry Mason <[EMAIL PROTECTED]> 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/>
