- From: Ian Hickson <ian@hixie.ch>
- Date: Sat, 27 Jun 2009 07:14:36 +0000 (UTC)
- To: John Fallows <john.fallows@kaazing.com>
- Cc: "public-html-comments@w3.org" <public-html-comments@w3.org>
I believe I made the changes suggested below at some point in the past few months, but for some reason forgot to respond to this e-mail. In any case, there is now an 'error' event fired when the connection is failed for the last time. Note that the feature has changed quite significantly and has been moved to a separate specification: http://dev.w3.org/html5/eventsource/ Please let me know if the changes are not satisfactory. On Fri, 6 Feb 2009, John Fallows wrote: > > When building HTML 5 applications that leverage one or more SSE > streams, it may be important to change the application behavior (such > as updating the user interface) when an SSE stream aborts retry, due > to some network or server error condition. > > At present this does not seem possible, see the following scenario as > an example: > > 1. application adds message listener to an event-source > 2. application adds http://www.sse.org/stream to an event source > 3. application updates user interface to indicate live connection > (possibly dormant - no data yet) > 4. network or server error causes SSE stream to complete > 5. SSE implementation automatically retries connection (after waiting > "retry" milliseconds) > 6. network or server failure causes SSE to abort retry, no longer connected > 7. application continues to display user interface assuming everything > still OK (incorrect) > > So, in an effort to address this problem, the following proposal makes > a minor enhancement to the existing SSE specification, such that error > conditions can be detected by the application and handled > appropriately. > > Reuse the onerror concept from media elements to deliver a > ProgressEvent named "error" to the error event listeners on the > event-source element, and add an equivalent onerror attribute to the > event-source element for completeness. > > Now, repeating the same scenario, with the enhanced event-source > proposal, we get the following: > > 1. application adds message listener to an event-source > 2. application adds error listener to an event-source > 3. application adds http://www.sse.org/stream to an event source > 4. application updates user interface to indicate live connection > (possibly dormant - no data yet) > 5. network or server error causes SSE stream to complete > 6. SSE implementation automatically retries connection (after waiting > "retry" milliseconds) > 7. network or server failure causes SSE to abort retry, no longer connected > 8. SSE implementation delivers "error" event to event-source error listeners > 9. application updates user interface to indicate disconnected stream (correct) > > The error event would likely need to be delivered for any usecase > where the SSE implementation ceases to retry connection, and the > ProgressEvent would need to include a source URL that matches the now > broken stream URL previously added to the event-source by the > application because a single event-source element can have multiple > event streams. > > Adding the source URL to ProgressEvent would have the added benefit of > allowing the same JavaScript function to be directly reused on more > than one media element. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Saturday, 27 June 2009 07:15:12 UTC