W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

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

From: Sullivan, Bryan <BS3131@att.com>
Date: Thu, 30 Apr 2009 19:31:23 -0700
Message-ID: <8080D5B5C113E940BA8A461A91BFFFCD0DF4F56A@BD01MSXMB015.US.Cingular.Net>
To: "Robin Berjon" <robin@berjon.com>
Cc: "public-webapps" <public-webapps@w3.org>
Hi Robin,
I appreciate the consensus on the required attribute. 

The duration attribute is an attempt to address the more fine-grained "needs vs policy" alignment that is hinted at in the "required" flag. As widget runtime environments are deployed with policy controls on what can be accessed (e.g. OMTP's BONDI), we need to figure out how to let users know as soon as possible in the widget lifecycle (i.e. discovery/installation/use) that a widget will not work unless it is allowed certain permissions in the user's device. It is undesirable for users to find out that a widget will not work after having gone through the trouble of downloading it (and maybe paying). So some expression of the intended behavior (or necessary permissions) of the widget is needed, more fine grained than simple access to an API. Alternatively, some way for the widget or widget source (e.g. app store) to discover the permissions that will apply to the widget could be provided.

However the "required" flag is at least a good step in the right direction, and I am OK with postponing the "duration" attribute for further discussion.

Best regards,
Bryan Sullivan | AT&T
-----Original Message-----
From: Robin Berjon [mailto:robin@berjon.com] 
Sent: Thursday, April 30, 2009 7:54 AM
To: Sullivan, Bryan
Cc: public-webapps
Subject: Re: [widgets] Comments to <access> element text

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.

> 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.

-- 
Robin Berjon - http://berjon.com/
     Feel like hiring me? Go to http://robineko.com/
Received on Friday, 1 May 2009 02:32:07 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:31 GMT