Warning:
This wiki has been archived and is now read-only.

Push API

From WEBAPPS
Jump to: navigation, search

Push API Info

Current editor's draft: http://dvcs.w3.org/hg/push/raw-file/default/index.html

Use Cases

From http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0008.html

  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.
    1. Objective: Don't drain the battery.
    2. Derived Requirements
      1. Ability to use shared-bearer delivery methods e.g. based upon network signaling bearers (e.g. SMS, OMA Push/SMS), shared IP connections (e.g. OMA Push/UDP|HTTP|SIP, APNS, C2DM), or broadcast bearers (e.g. OMA Push/MBMS|BCAST|CBS).
      2. Ability to target pushed application data to specific apps.
  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.
    1. Objective: Don't waste bandwidth.
    2. Derived Requirements
      1. Same as (1)
      2. Ability to deliver pushed application data to targeted apps without the need for user intervention.
  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.
    1. Objective: Don't use the more expensive connection when a less expensive connection is also available.
    2. Derived Requirements
      1. Ability to invoke a targeted application if it is not running.