Re: Use Cases for Connectionless Push support in Webapps recharter

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