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

Re: [Server-Sent Events] Infinite reconnection clarification

From: Kornel Lesiński <kornel@geekhood.net>
Date: Tue, 12 Jun 2012 23:48:35 +0100
To: public-webapps@w3.org
Message-ID: <op.wftay9eyte2ec8@aimac.local>
On Tue, 12 Jun 2012 14:08:14 +0100, Glenn Maynard <glenn@zewt.org> wrote:

> What's the rationale behind the spec saying not to reconnect at all?  If
> the API makes each app individually handle reconnects, then not only does
> it push more work on web developers, it'll create two problems: apps that
> attempt reconnects too rapidly, and ones that--as Odin points out--don't
> reconnect at all because the developer didn't know he had to.

Indeed, I was under impression that SSE keeps connection persistent and  
does not require any error handling logic from authors.

I wrongly assumed that SSE enters permanent failed state only when  
recovery seems is impossible, e.g. 404 error or DNS error due to an  
authoritative NXDOMAIN response, and not when the error is caused merely  
by temporary lack of Internet connectivity.

Since SSE already recovers from unexpectedly closed connections, I think  
it should be safe for authors to assume it will always reconnect when  
possible. IMHO the spec should require UAs to reconnect whenever possible.

Having "fire and forget" API is a very attractive option. Writing and  
testing error recovery code, activated only in rare cases, is not fun and  
won't work for the web.


Pusher is a popular service that provides what SSE was supposed to do, but  
over Web Sockets, and their library reconnects automatically:
http://pusher.com/docs/client_api_guide/client_connect#connection-states

I think that's a good model to follow.

-- 
regards, Kornel Lesiński
Received on Tuesday, 12 June 2012 22:49:03 GMT

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