RE: [widgets] Comments to <access> element text

Marcos,
Since the <access> element and the widget standards themselves are new, I can't provide an example of an app store that addresses such issues. App stores tend to serve a narrow set of devices today, and the vision for widgets overall is that they are much more interoperable and can thus reach a much broader set of devices. Variations in capabilities and security policies will be something that must be addressed as soon as possible in the widget experience, and the most logical place for this is in the app store (a loose term for where the user discovers/obtains widgets), although a test of compatibility could also occur on the device (assuming the user did not have to pay for the widget first). To provide a good user experience, the app store could use available information to select widgets that are compatible with the user's device, or the device could check compatibility at install time.

In the case of the resources identified by <access>, widgets may be designed to use a variety of them. As close to a specific example I can give (recognize that I expect the variety of widgets and their relationships to content/service resources to be much wider) is:
- a social networking widget is designed to use the HTTP-based API's provided by various social network providers, and includes the API URI's in <access> elements
- some of these resources may not be accessible due to policies in effect for the user and/or service provider
- the widget is nonetheless designed to work with some of the social networks via an alternate resource, e.g. an API proxy provider, which is allowed per policy
- the widget is thus usable on devices in which at least the API proxy resource is accessible: thus it is "required", and the others "optional"

There are various valid reasons (validity of course here being in the eye of the user and/or service provider) for variation in resource accessibility, and these can be expressed as policies e.g. via BONDI, which can be used in the compatibility decision process. With the complimentary expression of *need* in the <access> element, we can support a complete system of compatibility verification, without widget-package-external metadata (e.g. something maintained in a proprietary way as part of an app store widget cataloging system).

Best regards,
Bryan Sullivan | AT&T
-----Original Message-----
From: Marcos Caceres [mailto:marcosc@opera.com] 
Sent: Saturday, May 02, 2009 2:30 AM
To: Sullivan, Bryan
Cc: Robin Berjon; public-webapps
Subject: Re: [widgets] Comments to <access> element text

I'm still not convinced, can you give me a real life example? Or point 
me to an AppStore that makes use of this?

Kind regards,
Marcos


On 5/1/09 8:36 PM, Sullivan, Bryan wrote:
> Marcos,
> I believe it will get used, because widget designers of widgets that use various
network based resources will need to adapt their widgets to the local 
policies of the host
device. A widget may be designed to use various resources if available, 
and work in
limited fashion or use backup options if some resources are inaccessible 
on the target device.
Use of this flag ensures that widgets with such alternatives can reach a 
wider set of target devices,
because while presence of the <access> element is essential for 
resources to be accessible, those
that are optional can be known earlier. It 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, e.g. at the app store.
>
> Best regards,
> Bryan Sullivan | AT&T
> -----Original Message-----
> From: marcosscaceres@gmail.com [mailto:marcosscaceres@gmail.com] On Behalf Of Marcos Caceres
> Sent: Friday, May 01, 2009 8:36 AM
> To: Robin Berjon
> Cc: Sullivan, Bryan; public-webapps
> Subject: Re: [widgets] Comments to<access>  element text
>
> On Thu, Apr 30, 2009 at 4:53 PM, Robin Berjon<robin@berjon.com>  wrote:
>> Hi Bryan,
>>
>> On Apr 30, 2009, at 16:06 , Sullivan, Bryan wrote:
>>> Here are a couple of suggestions for the<access>  element
>>> (http://dev.w3.org/2006/waf/widgets/#the-access-element):
>>>
>>> Attributes
>>>
>>> (add two new attributes)
>>>
>>> required: Optional.
>>>
>> I'm happy to add a required attribute with the same semantics and processing
>> as those of the same attribute on<feature>. I think it makes sense to be
>> consistent here.
>>
>
> I can live with this if the rest of the WG wants it, but I don't get
> the sense this will get used much (i.e., required = "false'). So
> again, do we _REALLY_ need this?
>
>>> 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.
>>>
>> I don't think that hits the 80/20 mark. I think it's largely a UI decision,
>> not something that ought to be requested by the widget author. For instance
>> on the Mac I use Little Snitch, which tells me when any app tries to access
>> an address and port combination that I haven't granted access to, and it
>> allows me to provide access once/until quit/forever. That all happens at the
>> UI layer, it's not something that apps request (nor should it be as
>> irrespective of what they ask the decision should rest with me, the
>> all-powerful user). What's more if we add that we can add a lot of other
>> things such as roaming, time of day (which can influence the price of a byte
>> in some places), etc.
>>
>
> Agreed.

Received on Tuesday, 5 May 2009 04:59:46 UTC