- From: Arthur Barstow <art.barstow@nokia.com>
- Date: Fri, 13 Jan 2012 08:33:41 -0500
- To: ext Bryan Sullivan <blsaws@gmail.com>, public-webapps@w3.org, Ian Hickson <ian@hixie.ch>, Doug Schepers <schepers@w3.org>, Charles McCathieNevile <chaals@opera.com>
Hi All, With respect to the charter, the SSE snippet currently says: [[ Server-Sent Events - An API for opening an HTTP connection for receiving push notifications from a server in the form of DOM events. The API is designed such that it can be extended to work with other push notification schemes such as Push SMS. ]] Is the above sufficient to cover the UCs Bryan proposes? If not, what specific change(s) is needed? Hixie - what are your thoughts on these UCs and how they would be spec'ed? For example, would they be in a different spec, an L.next type spec? (FYI, the minutes from November 1 discussion [that I did not attend] are <http://www.w3.org/2011/11/01-webapps-minutes.html#item10>). -AB On 1/3/12 6:51 PM, ext Bryan Sullivan wrote: > I had an action item to provide some use cases for the Webapps > recharter process, related to the "Push based on extending server-sent > events" topic at the last F2F (draft API proposal that was presented: > http://bkaj.net/w3c/eventsource-push.html). > > The intent of the action item was to establish a basis for a Webapps > charter item related to extending eventsource (or coming up with a new > API) for the ability to deliver arbitrary notifications/data to > webapps via connectionless bearers, as informationally described in > Server-Sent Events (http://dev.w3.org/html5/eventsource/). > > Here are three use cases: > > 1) One of Bob’s most-used apps is a social networking webapp which > enables him to remain near-realtime connected to his friends and > colleagues. During his busy social hours, when he’s out clubbing, his > phone stays pretty much connected full time, with a constant stream of > friend updates. He likes to remain just as connected though during > less-busy times, for example during the workday as friends post their > lunch plans or other updates randomly. While he wants his favorite app > to remain ready to alert him, he doesn’t want the app to drain his > battery just to remain connected during low-update periods. > > 2) Alice is a collector, and is continually watching or bidding in > various online auctions. When auctions are about to close, she knows > the activity can be fast and furious and is usually watching her > auction webapp closely. But in the long slow hours between auction > closings, she still likes for her webapp to alert her about bids and > other auction updates as they happen, without delay. She needs for her > auction webapp to enable her to continually watch multiple auctions > without fear that its data usage during the slow periods will > adversely impact her profits. > > 3) Bob uses a web based real-time communications service and he wants > to be available to his friends and family even when his application is > not running. Bob travels frequently and it is critical for him to > optimize data usage and preserve battery. Bob’s friends can call him > up to chat using video/audio or just text and he wants to make sure > they can reach him irrespective of what device and what network he is > connected at any given time. > > Comments/questions? >
Received on Friday, 13 January 2012 13:34:50 UTC