On Tue, 12 Jun 2012 14:08:14 +0100, Glenn Maynard <gl...@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
