Re: Devices as Virtual Web Services

On Wed, 20 Jan 2010 18:03:03 +0100, Max Froumentin <maxfro@opera.com>  
wrote:

[Also note that this is a response to ACTION-84, I'm hanging my answer off  
Max's, because it's partially already in alignment with it]

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

- The API can be designed specifically around the problem it intended to  
to solve.  With REST you have to create the API around two constraints:  
What you are intending to do, and REST itself.

> DAP as a REST service means:

* DAP as REST also requires that a discovery mechanism is specified
* Error handling needs to be defined in terms of http
* Access control needs to be specified in terms of the same-origin policy  
and CORS.

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

Note that "including Comet support" pretty much would mean that a solution  
is pretty much equivalent to ditching REST.

> - we're not sure yet if every feature of DAP is mappable to a REST  
> concept.

If all you have is a hammer, every problem looks like a nail. I don't  
neccesarily think it is a good idea, though.  It would feel downright  
painful to do POST to a camera to set the aperture or iso.

> - we're not sure how to solve the URI scheme problem.

The URI scheme problem is probably best solved by not actually creating a  
new scheme.  The downside to that is that we would probably need to  
(ab-)use http for the purpose. The upside to http is that you can, when  
suitable, expose services to a local network.

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

I fully agree with that.

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

Agreed.

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

Agreed.
-- 
Arve Bersvendsen

Opera Software ASA, http://www.opera.com/

Received on Tuesday, 2 February 2010 08:07:18 UTC