- From: Glenn Adams <glenn@skynav.com>
- Date: Sun, 8 Jan 2012 22:51:40 -0700
- To: Charles Pritchard <chuck@jumis.com>
- Cc: Bryan Sullivan <blsaws@gmail.com>, "public-webapps@w3.org" <public-webapps@w3.org>
- Message-ID: <CACQ=j+cjiq_JRXmtQXZCE2ey-=Oy+oMoJBokSPRG9OTxB7365g@mail.gmail.com>
good summary... perhaps if you label/title each use case with the following summaries, the intention will be more clear (I for one did not discern these three goals from the stated UC language) On Wed, Jan 4, 2012 at 6:50 PM, Charles Pritchard <chuck@jumis.com> wrote: > a) Don't drain the battery. > b) Don't waste bandwidth. > c) Don't use the more expensive connection when a less expensive > connection is also available. > > > On Jan 4, 2012, at 6:38 PM, Glenn Adams <glenn@skynav.com> wrote: > > what are the qualitative differences (if any) between these three use > cases? > > On Tue, Jan 3, 2012 at 5:51 PM, Bryan Sullivan < <blsaws@gmail.com> > blsaws@gmail.com> 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> >> 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/> >> 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? >> >> -- >> Thanks, >> Bryan Sullivan >> >> >
Received on Monday, 9 January 2012 05:52:30 UTC