RE: Devices as Virtual Web Services

Agree, still you need standards so that a XYZ application that asks for Camera service on device A will work with device B.

Dzung Tran
Intel Corp

From: public-device-apis-request@w3.org [mailto:public-device-apis-request@w3.org] On Behalf Of Kenton Varda
Sent: Monday, January 25, 2010 12:24 PM
To: Max Froumentin
Cc: Robin Berjon; public-device-apis@w3.org
Subject: Re: Devices as Virtual Web Services

I don't think anyone debates the fact that writing code against a REST service will not be as convenient as writing code against a Javascript API.  However, I think the other advantages greatly outweigh this inconvenience.

I think the purpose of the standards process is to facilitate interoperability, *not* to make developers' lives easy.  For the latter task, "the market" already does an excellent job.  Myriad libraries already exist for simplifying the task of using REST services.  None of these are standardized, nor should they be, as standardization would make it hard for them to innovate.  I think that the market is likely to be able to come up with much better Javascript-level APIs than the standards committee would.

As for the goal of interoperability, I think that goal is much better served by basing the standards on REST.  HTTP is already a standard protocol with standard access control mechanisms, and its use is well-understood.  By exposing devices as REST services, we make the problem of implementing a new device equivalent to the problem of writing a new web service, for which many tools and much expertise already exist.  Exposing a new device may be as easy as providing a local web server implementing it, perhaps with no browser changes needed at all.  Providing access to non-local devices and writing non-browser-based software that accesses devices both become trivial even though those were not our intentions.  I think all of this means that a standard based on REST is likely to get much wider use than a standard based on Javascript APIs.  As a nice bonus, creating the standard itself would be much less work.

On Wed, Jan 20, 2010 at 9:03 AM, Max Froumentin <maxfro@opera.com<mailto:maxfro@opera.com>> wrote:
On 20/01/2010 15:32, Robin Berjon wrote:
Hi all,

as discussed previously, here are my notes about this specific issue:

  http://dev.w3.org/2009/dap/docs/virtual-ws.html

Comments welcome!

DAP as an API means:
- It is implemented in the browser code, or a plugin
- It is simple to use for webapp authors (because it was designed so)

DAP as a REST service means:
- more work for webapp authors (and there are thousands more of them than browser implementers.)
- hence, webapp authors will almost be forced to use a framework
- that framework will probably need to include Comet support
- we're not sure yet if every feature of DAP is mappable to a REST concept.
- we're not sure how to solve the URI scheme problem.

Based on the above, and on the assumption that DAP is meant to be a convenience for webapp authors, APIs seem simpler and superior.

But like John Kemp has said, it's a good thing to keep REST implementations in mind when we design the API, since we can expect a few of them to be wrappers around REST APIs anyway.

Whether we should have a REST solution defined on top of the current API is something we may want to have a look at, but not a priority to me.

Max.