Re: [whatwg] Revised Plan for Server-sent DOM events
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/
Re: [whatwg] Revised Plan for Server-sent DOM events
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. 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
Re: [whatwg] Revised Plan for Server-sent DOM events
Anne van Kesteren wrote: - 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? Simply get rid of, or significantly raise, the limit? Standards work related to this probably belongs (and conceivably is already happening) in an HTTP protocol forum. I did some poking around recently, and browser behavior related to this limit is fairly varied, depending on context. Dan
Re: [whatwg] Revised Plan for Server-sent DOM events
Dan Mosedale wrote: Anne van Kesteren wrote: - 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? Simply get rid of, or significantly raise, the limit? Standards work related to this probably belongs (and conceivably is already happening) in an HTTP protocol forum. I did some poking around recently, and browser behavior related to this limit is fairly varied, depending on context. You're talking about the default/standard behavior, right? In FF this value can be changed (network.http.max-connections-per-server etc.) - but telling from your e-mail address you probably already know that. :-) Regards, Philipp Kempgen
Re: [whatwg] Revised Plan for Server-sent DOM events
On Sat, 05 Jan 2008 06:51:29 -, Henry Mason [EMAIL PROTECTED] wrote: - Unnecessary dependency on DOM Events This feature is inherently event-based. I think it does make sense to re-use existing framework for event handling. However, I haven't found use-case for remote triggering of standard events, like mouse and keyboard events. I always use my custom events, because I don't want to couple server-side code with details of particular user interface. - Redundancy with already existing techniques, especially XMLHttpRequest It's much simpler to use and allows browser to manage the connection. I propose that we remove support for non-message events; that is, allow only events with MessageEvent interface. +1 Scripts that need that functionality can create wrapper on client-side that will dispatch other types of events. 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. I don't see how it makes cross-domain messaging safe. Without Access-Control mechanism, what would prevent malicious site from reading event-source of e.g. users' gmail chat? (variant of CSRF attack) -- regards, Kornel Lesiński
