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

Re: Devices as Virtual Web Services

From: Robin Berjon <robin@robineko.com>
Date: Wed, 27 Jan 2010 11:58:06 +0100
Cc: "public-device-apis@w3.org" <public-device-apis@w3.org>
Message-Id: <DB297D9E-66A8-45DD-AE29-4B9E59FCFBB2@robineko.com>
To: Frederick Hirsch <frederick.hirsch@nokia.com>
Hi,

having thought about this some more.

On Jan 20, 2010, at 15:54 , Frederick Hirsch wrote:
> - the potential need for using a different protocol that isn't widely used (Bayeux Comet protocol),

Not necessarily. There are other options (though equally not much deployed at this point). More importantly, in the document I make the case that one could exclude APIs that require subscription notifications from using a LREST model and only look into it for those that don't (typically: Contacts, Calendar, Gallery).

> - use of a library to mask XMLHttpRequest details (is there open source here?),

I don't think that this is an issue. Yes there is a lot of open source available, and it's common practice.

> - some more slightly complex and careful coding required, potential quality risk

More than that I am worried about things that look like a good idea from a distance but don't quite fit up close. Not quite a square peg in a round hole but rather a somewhat roundish peg in a somewhat roundish hole.

The typical example is with synchronicity. With an API we can enforce the fact that a call that is a security entry point is asynchronous  with XHR that becomes the developer's decision. Now I'm all for giving people way more rope than they need to hang themselves and their dogs with, except where it may interact with the security layer.

> - the need to create a URI scheme, probably opaque, and

Maybe, maybe not  I'd flag this as a grey issue.

> - a performance cost of URI resolution.

That's a small thing, listed for completeness.

> - JSON definitions (an issue anyway, either approach?)

That's solvable.

> Do you have a pointer to Stephen's proposal regarding database approach?

No, it was made orally during the last f2f.

My conclusion regarding LREST tends to be that for most cases it doesn't seem like it could bring a big win. The exceptions are for APIs where I can see a solid use case for having the same protocol be used to access remote services (Calendar, Tasks, Contacts, and Gallery).

With traditional APIs we have models that we can follow and that are believed or known to work both at the functional and security levels (Geolocation and File Reader). More importantly: if security issues with the approaches taken by these two APIs occur, they will have to be solved (because they're shipping), so by relying on the same model, we get the win that we share the solutions.

LREST introduces unknowns and if it turns out to be broken then we're on our own. Contrary to what has been said, we do have security solutions that work for APIs (at least I hope they work since they're deployed in browsers I use) whereas we'd have to solve them again (or fallback to the same ones, only somewhat awkwardly) with LREST.

I don't want to shut the discussion down but I'd like to suggest that we restrict the area of investigation to domains where the remote service access use cases bring enough value to compensate for the exploratory overhead, the aforementioned Calendar, Tasks, Contacts, and Gallery. Thoughts?

--
Robin Berjon
  robineko  hired gun, higher standards
  http://robineko.com/
Received on Wednesday, 27 January 2010 10:58:36 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:41 UTC