W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2012

Re: Use Cases for Connectionless Push support in Webapps recharter

From: Arthur Barstow <art.barstow@nokia.com>
Date: Fri, 13 Jan 2012 08:33:41 -0500
Message-ID: <4F1032B5.5020206@nokia.com>
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 

(FYI, the minutes from November 1 discussion [that I did not attend] are 


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

This archive was generated by hypermail 2.3.1 : Wednesday, 11 February 2015 14:36:56 UTC