Here is my input re my action for use cases to the WARP spec (http://www.w3.org/2008/webapps/track/actions/348)
Use cases for WARP spec related to the following access element attributes (add two new attributes):
required: Optional.
- A boolean attribute that indicates whether or not this resource is essential to the operation of the widget, and thus must be accessible to the widget at runtime. In other words, the required attribute denotes that a resource is absolutely needed by the widget to function correctly, and without the availability of this resource the widget serves no useful purpose or won't execute properly. The default value when this attribute is absent is true, meaning that the resource must be made available to the widget by the widget at runtime.
duration: Optional.
- One of "one-shot", "session", "blanket", indicating the duration of the access essential to the operation of the widget, and thus must be allowed to the widget at runtime. In other words, the duration attribute denotes the minimum period over which the widget requires access to the resource, without further user action authorizing continued access. Without this minimum duration the widget serves no useful purpose or won't execute properly.
- "one-shot" means that the widget requires no extended access authorization, and the runtime can prompt the user for every access attempt, if required.
- "session" means that each time the widget is executed, the widget must have free access to the resource after at most one user prompt for access confirmation.
- "blanket" means that once the widget is installed, it requires free access to the resource without any user prompts for access confirmation.
The default value when this attribute is absent is "session".
The primary use case for these attributes is the ability to know as early as possible in the discovery/download/use process, e.g. at the app store or at latest during installation, whether a widget is compatible with the security policy of the widget user agent. The "all or nothing" nature of the access element as it stands is not consistent with the feature element, but there can be just as necessary a "need to know" related to network resource access permissions. If optional resources are not accessible, widget authors can take steps to gracefully degrade widget functionality or use alternate (perhaps, less effective or efficient) means to obtain the same services. Use of the required flag ensures that widgets with such alternatives can reach a wider set of target devices, and will thus result in a better user experience as the true compatibility of the widget with the target device can be determined as early as possible in the discovery/download/use process.
Similar to the required flag, the way in which a widget needs to use network resources is as well an important criteria of compatibility. Some widgets may simply be unusable unless they have automatic/unrestricted access to network resources. Other widgets may be able to reach a much broader target market if they can convey up-front that they are not dependent upon such unrestricted access.
Best regards,
Bryan Sullivan | AT&T
