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.
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
- P&C: make the <name> element mandatory in next version of spec (post 1.0); request by Michael Cooper of P&F WG; 7-Oct-2009
- P&C: MIME type detection and support for additional media types; request by Michael Cooper of P&F WG; 27-Aug-2009
- Allow any CSS length unit for icons.
- Add a required attribute to the access element; see Proposal by Bryan Sullivan and related thread from 30-Apr-2009.
- Add a duration attribute to the access element; see Proposal by Bryan Sullivan and related thread from 30-Apr-2009.
- add a proper API for icons.
- add a screenshot element, as was previously defined in widgets 1.0; see proposal to drop screenshot for v1
- 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
Scenario 1. Widgets in High Latency Environments
To be written...
Scenario 2. Widgets in the Enterprise
To be written...