View source

From WEBAPPS

You do not have permission to do that, for the following reasons:

• The action you have requested is limited to users in one of the groups Sysops, webappsEditors.
• You must confirm your e-mail address before editing pages. Please set and validate your e-mail address through your user preferences.

You can view and copy the source of this page:

=== 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 Wish List ==== The following is a wish list of features we would like to include in version 2.0. This section is intended for brainstorming ideas: * P&C: make the <name> element mandatory in next version of spec (post 1.0); [http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0083.html request by Michael Cooper of P&F WG]; 7-Oct-2009 * P&C: MIME type detection and support for additional media types; [http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0843.html 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 [http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0447.html Proposal by Bryan Sullivan] and related thread from 30-Apr-2009. * Add a ''duration'' attribute to the access element; see [http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0447.html 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 [http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0197.html 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 ==== Use Cases ==== ===== Scenario 1. Widgets in Rural Environments ===== To be written... ===== Scenario 2. Widgets in the Enterprise ===== To be written... ==== Design Goals ==== ==== Requirements ==== R1. xxxx

Return to Widgets2 UC&R.