Re: [WARP] Last Call comments (1)

Marcin Hanclik wrote:
> Hi Marcos,
>
> Re 99% fulfillment of the needs:
> As stated in my original email, one of the targets is that<access>  is not an obstacle for DAP.
> It is currently undefined how the related access control will be done and we would probably want to avoid the situation that<access>  is deprecated once DAP is ready with their model.
> So we may fulfill 99% of the needs now, but 1% in a few months with the<access>  element.
> That is why I proposed a more robust and extensible (hopefully future-proof) design of the functionality based on<feature>  element.

The design of feature does not exclude the option you suggest. It might 
be that there are two ways of doing the same thing. However, the 
particular use case (getting access to Web resources) is better served 
by <access> then by <feature>.

And I'll be totally impressed if DAP can get access requests to be more 
concise than <access>. Competition is good, bring it!

>>>> What's more, the conditional character of<feature>  brings flexibility to the design of widgets/webapps and may be important from
>>> their usability point of view.
>>>
>>> I don't understand the above sentence, can you give me an example of
>>> what you mean?
>
> Here I refer to the absence of the @required attribute on<access>  element and its presence on<feature>  element.
> By flexibility I mean the fact that access to some web resource could be conditional (i.e. not-required).
> Let's say my widget wants to retrieve resources from 2 websites / domains.
> One website provides the core functionality of the widget, i.e. the resources from it are mandatory/required, instantiation of the widget without access to those resources makes no sense etc.

The difference you are missing here is that <feature> is coupled to the 
device capability (something close to me, something I control that is 
fairly static). Access it coupled to the Web (something away from me, 
something I do not control, something completely volatile in space and 
time).

For <access> it makes no sense to have required as:

   1. a required Web service can go down at any point or become 
unavailable.
   2. a required Web service may redirect.
   3. a required Web service may move.
   4. I list more fails below...

I understand you are looking at this from a policy stand point, whereby 
the device block denies access to a request to a web resource:

device-policy -> deny -> *.google.com
widget -> access -> *.google.com -> Widget fail? route around the 
problem (e.g., proxy through allowed domain, give middle finger to policy).

So, the semantics of "required" on <access> would mean: "I require that 
the device *policy* make this available to me, as reaching the resource 
outside the context of the device is completely coincidental."

This is where required on access makes no sense: if the policy denies 
access, even if requested by the author, then the widget won't work 
anyway. A widget developer will have to deal with not having network 
access regardless, as network connections may not be available at any 
point in time through the lifecycle of a widget ("this is the Web: where 
anything goes and nothing is guaranteed").

> The second website provides additional functionality, a kind of nice-to-have for my widget. So access to the resources from this website is optional (@required=false).

Like I said above, this kind of declaration does not make any sense. The 
developer does not control the end-point (or the x number of connections 
needed to reach that end point). There could be a zillion things in the 
way of blocking access to a resource a widget is having to reach on the 
Web, on the device, etc.

On the Web, there is no such thing as guaranteed delivery. Declarations 
of "required" for network resources does not make any sense. Nothing can 
ever be "required" if it depends on the Web. That is the nature of the 
massively distributed networked environment.

Example:
   Resource X is REQUIRED.
FAILS:
   Device blocks access by policy.
   User runs out of credit on phone 50% through download.
   Government intervenes (e.g., China, Australia).
   Server over capacity (fail whale!).
   dns can fail.
   phone gets dropped in toilet.
   etc.

Kind regards,
Marcos

Received on Tuesday, 8 September 2009 11:57:23 UTC