RE: [EventSource] Comments to the current draft

On Mon, 7 Dec 2009, SULLIVAN, BRYAN L (ATTCINW) wrote:
>
> 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've added a mention of data usage savings, though I've avoided the use of 
the word "resources" since that term really is way too overloaded already.


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

I started adding this reference, but in attempting to double-check the 
URI, I found that it is impossible to read the document without agreeing 
to a license, so I couldn't finish checking the reference. Is there a URL 
that is to the actual spec rather than to a list of specs?


> Ian wrote:
> > On Tue, 27 Oct 2009, SULLIVAN, BRYAN L (ATTCINW) wrote:
> > > 
> > > 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.
> 
> Thanks. I'm guessing "relevance" means to the web application, and not 
> just that natively supported by the user agent.

The context here is what formats are allowed to be supported by user 
agents. By "relevant", I mean the formats have to be something that could 
theoretically be supported in a way that fits the API -- it has to be 
something that encodes discrete events, for instance.


> What "makes sense" is still a key question to me - I'm not sure exactly 
> why an image file (encoded) would not make sense [...]

No specification defines how you turn an image/png file into a set of 
events, so I don't understand what it would mean for a user agent to 
support image/png as an event source format.


> > > "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?
> 
> 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"?

The idea is that instead of just talking to www.example.com, you would 
talk to www1.example.com and www2.example.com and so on. How exactly this 
maps to DNS records is not my area of expertise. 


> > > "Allowing the user to enable..." is also likely an experience-killer.
> > 
> > Indeed, it's not ideal. It's an option, though.
>
> 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 browser is the one that enforces the per-server connection limitation 
(per the HTTP spec). I agree that we should consider exposing this to the 
Web app, but I think we should do that in a future version, once we know 
how much of a problem this is.

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

Received on Wednesday, 9 December 2009 12:29:17 UTC