W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2009

Re: [WARP] Last Call comments (1)

From: Marcos Caceres <marcosc@opera.com>
Date: Mon, 07 Sep 2009 15:36:59 +0200
Message-ID: <4AA50C7B.4000800@opera.com>
To: Marcin Hanclik <Marcin.Hanclik@access-company.com>
CC: "public-webapps@w3.org" <public-webapps@w3.org>


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
Received on Monday, 7 September 2009 13:37:41 GMT

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