RE: [EventSource] Comments to the current draft

Ian,
Thanks for the responses. Several of my questions were obviously newbie-level re DOM3 Events etc and HTML5 terms. I will read up on those further to understand what's meant.

The new text in section 9 captures the discussion in the TPAC with a good balance of clarity and flexibility.

I suggest to change "This can result in considerable power savings." to "This can result in considerable resource savings, e.g. power and data usage."

I suggest we add an informative reference:

[OMAPush]
OMA Push, Open Mobile Alliance. June 2009.
The HREF on "OMA Push" should be http://www.openmobilealliance.org/Technical/current_releases.aspx. June 2009 is the latest release of the Push enabler.

Further responses added below as "[bryan]". Mostly acks of the response, and only a couple of followup questions.

Best regards,
Bryan Sullivan | AT&T

-----Original Message-----
From: Ian Hickson [mailto:ian@hixie.ch] 
Sent: Monday, November 30, 2009 6:52 PM
To: SULLIVAN, BRYAN L (ATTCINW)
Cc: WebApps WG
Subject: Re: [EventSource] Comments to the current draft

On Tue, 27 Oct 2009, SULLIVAN, BRYAN L (ATTCINW) wrote:
> 
> Re "The API is designed such that it can be extended to work with other 
> push notification schemes such as Push SMS.": what is meant by "Push 
> SMS"? Does this refer to OMA Push, i.e. the service enabler defined by 
> the Open Mobile Alliance (OMA)? As I am the chair of the OMA Content 
> Delivery (CD) working group, and as convener and a key contributor to 
> the work on OMA Push, I would like to discuss the potential synergy 
> between Server Sent Events and OMA Push, as complementary mechanisms in 
> an overall server sent events framework. But first I need to be sure of 
> what the "Push SMS" term refers to.
>
> Re "Such formats could include systems like SMS-push; for example 
> servers could use Accept headers and HTTP redirects to an SMS-push 
> mechanism as a kind of protocol negotiation to reduce network load in 
> GSM environments.": This statement should be clarified. What's meant by 
> "use Accept headers and HTTP redirects to an SMS-push mechanism " is 
> unclear. If the client is offline, webapp servers can use OMA Push API's 
> (including the OMA Push Access Protocol) to initiate delivery of Push 
> messages to the user agent, including the text/event-stream MIME type 
> (since OMA Push supports any MIME type). The latest version of the OMA 
> Push specification (OMA Push 2.2) defines an abstract interface via 
> which web applications can register for OMA Push events, and this 
> interface can be supported through a Javascript-callable API (in 
> development).

I've tried to address these, as discussed here:

   http://www.w3.org/Bugs/Public/show_bug.cgi?id=8359

[bryan] As noted above, the new text looks good.

> Re "User agents must act as if the connection had failed due to a
> network error if the origin of the URL of the resource to be fetched is
> not the same origin as that of the first script  when the EventSource()
> constructor is invoked.": what this means is unclear (at least to me).

It relies on terms defined in HTML5. You can see a version of this that 
includes cross-references properly in the WHATWG "complete.html" file:

   http://www.whatwg.org/specs/web-apps/current-work/complete.html
   (WARNING: very large file - some browsers can't handle this file)

[bryan] Thanks.

> Is this essentially referring to the same-domain restriction, i.e. an
> eventsource() domain must be the same as the script source domain?

To a first approximation, yes.

[bryan] Thanks.

> What is "the first script" (and does this imply that only one 
> eventsource() call is possible for a webapp)?.

The "first script" is a concept used to scope certain concepts that apply 
to APIs, like the current "origin", the current "URL character encoding", 
etc, as defined in HTML5 (and in answer to your parenthetical question: no).

[bryan] Thanks. It will be interesting to see multiple eventsource() calls in operation, and worker thread support.

> Re "If such a resource (with the correct MIME type) completes loading 
> (i.e. either the entire HTTP response body is received, or the 
> connection is closed somehow, whether by the server or by a network 
> error), the user agent must reset the connection.": this would seem to 
> say after each response, the connection must be reset ("the entire HTTP 
> response body is received"). This seems inefficient, if dropping the 
> HTTP connection is what is meant. Not only could the data connection be 
> then dropped, but at least the eventual HTTP connection reestablishment 
> is a significant expense, resulting in a high overhead of TCP chatter. 
> It would seem that keeping the connection alive and letting the server 
> decide when to drop the connection would be a better approach.
>
> Re "HTTP 204 No Content, and 205 Reset Content responses are equivalent
> to 200 OK responses with the right MIME type but no content, and thus
> must reset the connection.": same comment as above, seems very
> inefficient if what's meant is dropping the HTTP connection.

I've tried to clarify these, as per:

   http://www.w3.org/Bugs/Public/show_bug.cgi?id=8190

[bryan] Thanks, it is clearer now.

> Re "HTTP 200 OK responses that have a Content-Type other than 
> text/event-stream (or some other supported type)": "other supported 
> type" I suppose means some arbitrary MIME type supported by the user 
> agent. Are there any practical limitations on what MIME types can be 
> supported?

Well, they have to be formats that are relevant; I mean, image/png 
wouldn't make much sense. Beyond that, I don't believe so.

[bryan] Thanks. I'm guessing "relevance" means to the web application, and not just that natively supported by the user agent. What "makes sense" is still a key question to me - I'm not sure exactly why an image file (encoded) would not make sense, but no specific followup is needed to clarify at this point.

> Re "When a user agent is to reset the connection, the user agent must
> set the readyState attribute to CONNECTING, queue a task to fire a
> simple event named error at the EventSource object,... ": firing an
> error is strange given that to "reset the connection" is a normal step
> of event handling as described above when "the entire HTTP response body
> is received" or "HTTP 204 No Content" is received.

These are all basically error conditions in the context of API.

[bryan] Thanks. With the other clarifications this is fine.

> Re "The task source for any tasks that are queued by EventSource objects
> is the remote event task source.": can this statement be explained (with
> references as needed)? What is the "remote event task source"?

See HTML5 for details on these terms. Cross-references straight from the 
EventSource spec to the relevant HTML5 bits are available in the 
"complete.html" file, if you have a browser that's capable of loading that 
file, as discussed above.

[bryan] Thanks, will do.

> Re "This event stream format's MIME type is text/event-stream.": Does
> this imply that other MIME types cannot be used as event streams?

It's not intended to; can it be interpreted that way?

[bryan] Not really, it's clear on reflection that "this" refers to the example.

> Re "Since connections established to remote servers for such resources 
> are expected to be long-lived": this seems to conflict with the "reset 
> the connection" functions above. How can the connection be long-lived if 
> it is regularly reset by the user-agent?

It's only reset ("reestablished" now) in exceptional situations (like the 
server closing the connection).

[bryan] Thanks, this is now clear.

> Re "If the event name buffer is not the empty string but is also not a
> valid event type name, as defined by the DOM Events specification": what
> a "valid event type name, as defined by the DOM Events specification"
> is, is unclear. The DOM Events specification does not define what a
> valid event type name is, as far as I can tell. There is reference to
> "Application-specific event types should use a prefix string on the
> event type name to avoid clashes with future general-purpose event
> types." but no more specific guidance I can find. Please clarify.

Doug, can you clarify what I should say here? What term should I use to 
invoke the DOM3 Events concept of a valid event name?

[bryan] Thanks. The clarity for the DOM3 Events concept will help.

> Re "Otherwise, create an event that uses the MessageEvent interface, 
> with the event name message, which does not bubble, is not cancelable, 
> and has no default action.": sorry for the newbie type question, but 
> readers of this spec are likely to need the same guidance: please create 
> a link to what is meant by "bubble" etc. I'm sure this is some obvious 
> concept to browser designers, but is likely unknown to many spec 
> readers.

A basic understanding of the DOM Events model is assumed; it's going to be 
very difficult to use Server Sent Events if you don't understand DOM 
Events, since this is basically an API for DOM Events. :-)

[bryan] Thanks, I will get to know it.

> Re "Legacy proxy servers are known to, in certain cases, drop HTTP 
> connections after a short timeout. To protect against such proxy 
> servers, authors can include a comment line (one starting with a ':' 
> character) every 15 seconds or so.": Note the impact of long-lived 
> connections on proxy servers is very significant, especially for proxy 
> servers as typically deployed in mobile networks. Given that there is 
> value being provided by maintaining the connection (i.e. regular data 
> flow across the connection) then the impact is just part of providing 
> the data service - but developers of mobile webapps that use eventsource 
> should be encouraged to drop connections during low-event periods and 
> use connectionless Push methods (via an OMA Push server) to deliver the 
> events.

As per our discussions at TPAC, this is best achieved by extending the 
user agent to the network infrastructure. The spec mentions this now.

[bryan] Thanks, the proposed text is helpful.

> Re "Implementations that support HTTP's per-server connection limitation
> might run into trouble when opening multiple pages from a site if each
> page has an EventSource to the same domain. Authors can avoid this using
> the relatively complex mechanism of using unique domain names per
> connection, or by allowing the user to enable or disable the EventSource
> functionality on a per-page basis, or by sharing a single EventSource
> object using a shared worker. [WEBWORKERS]": this whole paragraph
> deserves more discussion. Does "Implementations that support HTTP's
> per-server connection limitation" refer to the *client* implementation
> or the *server* implementation?

Clarified.

[bryan] Thanks.

> "Unique domain names per connection" is unclear and does sound complex 
> and non-scalable.

It's not that complex, it "just" requires wildcarding in the DNS. How 
should I clarify this?

[bryan] Thanks. No change needed, I guess those familiar with the server implementation will understand it. Since I'm not familiar with this specific technique, is it intended that the client can use a random sub-domain (e.g. "e8d7yewd7yc.myserver.com") which is mapped to "myserver.com" since the DNS record is "*.myserver.com"? 

> "Allowing the user to enable..." is also likely an experience-killer.

Indeed, it's not ideal. It's an option, though.

[bryan] Thanks. Is there a specific way that the browser can detect a "per-server connection limitation"? If so, it (or the webapp, if there is an error event that discloses the condition) could react more gracefully (e.g. back off on the number of simultaneous connections, or allow the user to turn off/down the eventsource use for that domain).

> The shared worker concept seems to have some merit and should be further 
> explained, e.g. how would multiple eventsource requests (at the "boss" 
> thread layer) get passed through a worker thread and managed re events 
> coming back? Is this something that Javascript frameworks are expected 
> to develop support for?

This seems out of scope for the spec.

(The idea would be that you open one connection from a shared worker, and 
then expose it using the postMessage() infrastructure.)

[bryan] Thanks. This will be interesting to see in operation. I think it will be a key feature to clarify for developers (we can do that through our developer programs).

> Overall, the approach to the Server Sent Events API seems to rely
> heavily on two methods which have significant consequences in mobile
> networks. This may be what was referred to as "network load in GSM
> environments", but would benefit from being clarified in text as a more
> clear set of motivations to use alternate Push means (e.g. OMA Push)
> where available. The two methods are (a) persistent HTTP connections;
> (b) polling via intermittently re-established data connections and HTTP
> connections.

Indeed. This is not limited to EventSource, of course; TCP/IP in general 
assumes the network supports long-lived connections and intermittent 
packets relatively cheaply.

[bryan] Thanks. The next text clarifies the motivations well enough.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Tuesday, 8 December 2009 00:25:27 UTC