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?
Re: Use Cases for Connectionless Push support in Webapps recharter
On Fri, 13 Jan 2012, Arthur Barstow wrote: 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? Well there's two parts to it: the protocol, and the API. If there's an existing protocol for this and the browser vendors are interested in implementing it, I see no reason why we couldn't support this alongside the current text/event-stream-based API in the HTML standard, either as part of the same API or as a separate API (like WebSockets). If it needs a new protocol, then that should probably be addressed first. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Use Cases for Connectionless Push support in Webapps recharter
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 ch...@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 gl...@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 bls...@gmail.com bls...@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
Re: Use Cases for Connectionless Push support in Webapps recharter
That is correct, the essential value in notification bearer flexibility is resource conservation and contextual adaptability (eg bearer selection when conditions warrant a change or limit choices). On Wednesday, January 4, 2012, Charles Pritchard ch...@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 gl...@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 bls...@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). 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? -- Thanks, Bryan Sullivan -- Thanks, Bryan Sullivan
Re: Use Cases for Connectionless Push support in Webapps recharter
what are the qualitative differences (if any) between these three use cases? On Tue, Jan 3, 2012 at 5:51 PM, Bryan Sullivan bls...@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). 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? -- Thanks, Bryan Sullivan
Re: Use Cases for Connectionless Push support in Webapps recharter
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 gl...@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 bls...@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). 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? -- Thanks, Bryan Sullivan
Use Cases for Connectionless Push support in Webapps recharter
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? -- Thanks, Bryan Sullivan
