W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2012

Re: [Server-Sent Events] Infinite reconnection clarification

From: Odin Hørthe Omdal <odinho@opera.com>
Date: Tue, 12 Jun 2012 10:48:37 +0200
To: "Ian Hickson" <ian@hixie.ch>
Cc: "public-webapps@w3.org" <public-webapps@w3.org>
Message-ID: <op.wfr73bat49xobu@odinho-fido.oslo.osa>
On Tue, 12 Jun 2012 02:56:00 +0200, Ian Hickson <ian@hixie.ch> wrote:
> On Tue, 17 Apr 2012, Odin Hørthe Omdal wrote:
>> If I understand correcly, the spec expects the implementation to keep
>> reconnecting indefinitely, when the network cable is yanked.
>
> No. The spec says "Any other HTTP response code not listed here, and any
> network error that prevents the HTTP connection from being established in
> the first place (e.g. DNS errors), must cause the user agent to fail the
> connection." and "Once the user agent has failed the connection, it does
> not attempt to reconnect".
> (In particular, note that "reestablish the connection" only ever occurs  
> if
> the remote resource is actually obtained with the right MIME type.)

We implemented it like that in Opera, except that we do in fact try  
reconnecting a bit before giving up and firing the error event.

However, as I said, that's not what the others do, so we want to align  
somewhere - either us following the rest, or the rest following us. Not  
really important what way it goes.

Looking into it, however, I do see some nice benefits when keeping the  
connection always reconnecting like that.


If you're on a page on your phone, on a Wifi connection, you go away from  
your home and take the bus. After one hour you get to work, there you get  
a new Wifi connection and the web page on your phone starts doing what it  
was up to before - even though the web page author never really thought  
about that.

On the other hand, for rockstar web page authors, it's nicer to control  
that yourself. However, doing that, the browser doesn't know what you're  
doing in your setInterval calls, and thus it's a bit harder to be smart  
about it. If it is doing the reconnections itself, it can have different  
heuristics and algorithms to control the behaviour.


>> I tried yanking the network for 10+ minutes, and when I put the cable in
>> again, both Firefox and Chromium used 25 seconds to reconnect. When only
>> yanking it for one minute, the reconnection was much faster (2-5
>> seconds). This with *reconnection time* set to 500ms.
>
> As far as I can tell, none of that is conforming. If you yank the cable,
> they should retry once, then give up, per the spec.

So... To be really spec-conforming, we'd have to be superduper-strict? I  
wouldn't mind, but I *do* mind when the other engines do something  
completely different :-)

-- 
Odin Hørthe Omdal (Velmont/odinho) · Core, Opera Software, http://opera.com
Received on Tuesday, 12 June 2012 07:49:20 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:52 GMT