Widgets2 UC&R

Jump to: navigation, search

Widgets 2.0 Use Cases and Requirements

This page lists the use cases and requirements for version 2.0 of the Widgets Family of Specifications. It is a space to gather ideas potential ideas of what could go into a future specification.

Features ...

The following is a list of features, use cases, requirements, updates, etc. we could include in a future version of a widget spec or perhaps specifiy in an entirely new spec:

  • multiple authors should be allowed, and they should be localizable; File by Charles McCathieNevile on 8-Apr-2011
  • xml:lang should really only be used to indicate the language of content in an element. Filed by Richard Ishida; 20-May-2010
  • Add support for a stream-able format like gzipped tar files; Gregg Tavares; 28-Apr-2010
  • Config file: add a linking element that points to a stylesheet and to its target resource (an HTML or SVG file, say), and says, apply this stylesheet to this file; by Doug Schepers 11-Feb-2010
  • Allow any CSS length unit for icons.
  • add a proper API for icons.
  • A security framework defining what needs to be protected, how a security policy is defined (i.e. format, vocabulary) and how security policies could be provisioned or managed.
  • It should be possible to display the same instance of a Widget in multiple display modes at the same time (e.g. battery could have an icon state and a full app state) and react to user interactions in one display modes in the other display modes.For this purpose Widget V2 should specify an API for opening other browser contexts which will provide feedback to Widget User Agents based on the actions performed within that context.
  • The V1 Widget Update mechanism implies a "one at time" update model, one widget - one connection. This is highly inefficient if you have dozens of widget on a mobile phone to be updated frequently. V2 should specify mechanism to enable "intelligent" updates for multiple updates over a single connection
  • Eliptic curve algorithm support in Widgets Digsig
  • extensible metadata model for the manifest (see ACTION-241)
  • add manifest format/addType for mime types.
  • Current <content> model does not allow multiple views. How to manage multiple views of the same widget (i.e. dock mode, full screen) still referring to the same instance
  • In case of alternative representations of widget (i.e. Flash or HTML) Widget V2 should define fallback mechanism for <content> element
  • Extend actual widget metadata model for the widget manifest to match the requirements of securely accessing device resources and for Widget discovery
  • Investigate whether proxy management (i.e. default proxy, exceptions) should be addressed by Widget V2 or definitely leave it to hosting OS
  • Define a mechanism for "malicious" widgets revocation similar to Apple kill switch
  • Provide more use cases on the V2 autoupdate feature
  • Does Widget V2 still require the whole Html5 spec to be implemented?
  • Understand if cross-widget messaging requires an ad Hoc Api specification
  • need to add support extended language encoding extra field [ZIP]
  • some kind of author <confirm> element or <rating> that allows authors to warn about potential things in the application (e.g. "this widget contains adult themes").
  • allow automatic updates via SMS

Use Cases

Scenario 1. Widgets in High Latency Environments

To be written...

Scenario 2. Widgets in the Enterprise

To be written...

Design Goals


R1. xxxx