W3C home > Mailing lists > Public > public-device-apis@w3.org > February 2010

Re: Simple LREST toying

From: Anne van Kesteren <annevk@opera.com>
Date: Fri, 12 Feb 2010 09:31:36 +0100
To: "Frederick Hirsch" <frederick.hirsch@nokia.com>, "ext Robin Berjon" <robin@robineko.com>
Cc: "public-device-apis@w3.org" <public-device-apis@w3.org>
Message-ID: <op.u7z9yymq64w2qv@annevk-t60>
On Thu, 11 Feb 2010 19:40:49 +0100, Frederick Hirsch  
<frederick.hirsch@nokia.com> wrote:
> First I'm trying to understand why standardized Javascript APIs wouldn't  
> be more usable.  For local device invocation, they could simply be  
> called by code, if implemented on the device. If supported in a REST  
> scenario, a simple wrapper could dispatch to them, much like the code  
> you created dispatches to invoke custom flickr code. This seems to make  
> local access much easier while not preventing the REST alternative.

The thing is, that if REST becomes the more dominant scenario for this  
over time, which I think is the expectation, we have this redundant API  
lying around.

> Second, authorization can get hard without a policy mechanism. Say you  
> as the owner of pictures want to control access. Imagine you had 3  
> photos that only Max and I could look at, and 2 that only the WG could  
> view and the rest are world visible. It seems you would need to define a  
> policy to state that declaratively, then use authentication information  
> to authorize based on the policy. Does OAuth help in this case - I think  
> it is more focused on delegation of all activity of a specific user from  
> one server to another - a different problem.

It seems like this ought to be managed by the photo application. And based  
on the person accessing the data you either get a 401 or a 200.

Anne van Kesteren
Received on Friday, 12 February 2010 08:32:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:17 UTC