RE: [WARP] Last Call comments (1)

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.

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

Thanks,
Marcin


Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452  |  Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanclik@access-company.com

-----Original Message-----
From: Marcos Caceres [mailto:marcosc@opera.com]
Sent: Monday, September 07, 2009 3:37 PM
To: Marcin Hanclik
Cc: public-webapps@w3.org
Subject: Re: [WARP] Last Call comments (1)



Marcin Hanclik wrote:
> Hi Marcos,
>
>>> is pretty simple, logical, and gets the job done for most use cases.
>
> The above is not the case e.g. for mailto: or tel:, specifically if you want to be more specific/selective with the additional arguments (a la subdomains).

Access requests for those are not relevant, IMO. Those would be
controlled by the policy of the UA. (e.g., policy may say all 'tel:' and
'mailto:' are allowed and handled by the appropriate scheme handler -
the phone dialer or the mail app.)

I don't see any use case for <access uri="mailto:*@gmail.com"> or
<access uri="tel:+47*">. That's overkill, IMO.

<access> covers the common (+99%) use case of accessing stuff on the
Web. Like I said, other scheme handlers can handle tel, mailto, etc.
like is currently done by browsers.

> It is also not the case for the distinction between programmatic vs. declarative/URL (not sure how to name it :) ) access.
> Those aspects may be important from the DAP's security model perspective.

Key word here is "may": you are adding solutions before you have a
problem. Just focus on solving the issue at hand.

> "Most use cases" currently entails a few assumptions implicitly, e.g. relation to installation-time or dynamic access to the resource etc.

Let me make the assumptions explicit: Most use cases for Opera = the
Opera gallery of Widgets and what our developer community need and want.
They want access to, for instance, the flickr API, the Google APIs,
Twitter, etc. and the ability to mash up stuff really quickly,
painlessly, and easily. They (and I) want a super easy to use platform
that kicks ass for developing and delivering client-side applications.
My goal is to give that to them:) I'm sure your goals are the same.

In the future, they might want access to "features" provided by dap.
Hopefully, they won't have to request those through a feature element
(i.e., the APIs will just be there for them to use without requesting
them), but, in the unfortunate case that they do have to request them, I
want to make sure it's as simple as possible.

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


Kind regards,
Marcos

________________________________________

Access Systems Germany GmbH
Essener Strasse 5  |  D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda

www.access-company.com

CONFIDENTIALITY NOTICE
This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the
individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited.
If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.

Received on Tuesday, 8 September 2009 09:01:58 UTC