Re: Simple LREST toying

Robin

I took a look at this, and it seems to show how URL interception  
could work in the web case (obviously). Thanks for making this clearer.

Looking at this from a device local access viewpoint I have questions.

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.

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.

Finally, what is the relationship of these "magic URLs" and  
"features"? I'm not sure but it seems there may be one.

I'm looking forward to seeing more detail on the REST approach -  
thanks for the detail that shows the interface and degree of code  
required.

regards, Frederick (not as chair)

Frederick Hirsch
Nokia



On Feb 11, 2010, at 11:22 AM, ext Robin Berjon wrote:

> Hi,
>
> just to help clarify some ideas around LREST I put together a  
> really dirty and really ugly implementation of what a Gallery API  
> could be. It's up at:
>
>   http://dev.w3.org/2009/dap/docs/lrest/gallery-lrest.html
>
> (Note: it works in the latest FF, Safari, Chrome; not in the latest  
> Opera; untested on IE)
>
> The only real browser-level change that is makes is that  
> navigator.services.galleries is made to contain a list of galleries  
> for discovery. Each is described thus:
>
> interface Gallery {
>   readonly attribute DOMString name;
>   readonly attribute DOMString uri;
> };
>
> If you click on the button to list the galleries it does so. The  
> URIs that they use are "magic", i.e. they have the form  
> "unicorn:flickr/tag/dahut" (I picked unicorn, of course it could be  
> anything).
>
> The rest of the code just makes regular XHR/AJAX calls to that URI,  
> it just so happens that they become intercepted and transparently  
> get an answer that matches the request, so "unicorn:flickr/tag/ 
> dahut" will get you a bunch of images tagged as "dahut".
>
> This is implemented by wrapping around the native XMLHttpRequest  
> and taking over for the unicorn: URIs. XHR requests to regular URIs  
> are undisturbed (as can be tested). Below the hood it calls out to  
> Flickr's API, but that's just a detail: it could just as well be  
> local or another remote source.
>
> It makes use of a fake Infobar to show how, if the service is  
> implemented by the browser itself, it can be integrated with the  
> existing flow.
>
> This only does a simple GET, but obviously it could work with other  
> methods.
>
> So overall nothing Earth-shattering, but it might clarify how this  
> could work in our collective mind. I'd be interested in hearing how  
> some might plug better auth on top of this (feel free to hack on it  
> in CVS).
>
> --
> Robin Berjon
>   robineko — hired gun, higher standards
>   http://robineko.com/
>
>
>
>
>

Received on Thursday, 11 February 2010 18:41:28 UTC