Simple LREST toying

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 16:23:20 UTC