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> 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.
>
>