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

Re: Devices as Virtual Web Services

From: Frederick Hirsch <frederick.hirsch@nokia.com>
Date: Sat, 23 Jan 2010 10:54:37 -0500
Cc: Frederick Hirsch <frederick.hirsch@nokia.com>, Robin Berjon <robin@robineko.com>, "public-device-apis@w3.org" <public-device-apis@w3.org>
Message-Id: <069A2831-7447-4DE0-87AE-2179B9AD72F9@nokia.com>
To: ext Max Froumentin <maxfro@opera.com>

regards, Frederick

Frederick Hirsch

On Jan 20, 2010, at 12:03 PM, ext Max Froumentin 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  
> is something we may want to have a look at, but not a priority to me.
> Max.
Received on Saturday, 23 January 2010 15:55:27 UTC

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