- From: Ian Hickson <ian@hixie.ch>
- Date: Wed, 12 Nov 2008 20:13:45 +0000 (UTC)
- To: John Fallows <john.fallows@kaazing.com>
- Cc: "public-html-comments@w3.org" <public-html-comments@w3.org>
On Mon, 27 Oct 2008, John Fallows wrote: > > [...] > > As currently specified, Server-sent Events makes [reconnecting] > seemingly impossible to achieve without also specifying some unintended > semantics. One can set "retry" to zero, then complete the response > normally, causing the client to reconnect right away (and be load > balanced to a different node in the cluster than previously used). The > reconnected stream can immediately reset the "retry" to something on the > order of 2-3s, but what happens if the network or server fails before a > successful reconnect? When is the value of "retry" automatically reset > by the client to the default value? > > If the semantics of "retry" are intended for failure recovery only, then > we need another way to trigger a reconnect for the non-failure use-case. > > For example: > .... > reconnect\n > \n > [end-of-stream] I've added this to the spec, but commented out. I think this is something that we should add, but I'd like to wait for the browsers to have the basics implemented before making this more complex. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 12 November 2008 20:14:24 UTC