Re: Devices as Virtual Web Services

Claes

Thanks for your message.


>  The device services are accessed by the local web server through  
> native device APIs and are accessed by the browser or widget engine  
> through http/REST.


Is the executive summary here:

1. Standardize Javascript APIs for all device functionality in the  
DAP charter

2. Expose REST interface to those APIs where appropriate, using those  
APIs to implement

Further, do #1 first.

Is that a correct summary of what you suggest?


regards, Frederick

Frederick Hirsch
Nokia



On Feb 10, 2010, at 6:41 AM, ext Nilsson, Claes1 wrote:

> Hi,
>
> I have so far been quit regarding the discussion on REST APIs.  
> However, I have followed the discussion with great interest and I  
> have made the following conclusions regarding the REST approach.
>
> Implementing local device APIs through a local web server / REST  
> seems as an attractive and flexible implementation solution. The  
> device services are accessed by the local web server through native  
> device APIs and are accessed by the browser or widget engine  
> through http/REST. When new device APIs should be added the local  
> web server is updated and downloaded to the device and updated JS  
> libraries/frameworks are used.
>
> Accordingly: Web Apps API extensibility is (ideally at least)  
> achieved without the need to update the browser/widget engine or  
> any native device code under the condition that the device's native  
> APIs are powerful enough.
>
> However, the question remains: What should be standardized, the "JS  
> level" or the "REST level"?
>
> It seems to me that there are advantages in standardizing the REST  
> level. In the discussion the following have been mentioned:
>
> - REST APIs are language independent
> - A REST API to a service situated "anywhere" (device, accessory,  
> PC, server) can be accessed from "anywhere"
> - REST APIs make it possible to leverage on existing HTTP access  
> control mechanisms
> - Developers use JS APIs, which hide the complex "REST coding",  
> within their favorite JS library/framework anyway and these should  
> not be standardized.
>
> My guess is that the REST approach is evolving within the web.  
> However, we also have JS API standards/implementations such as  
> Bondi, JIL, Symbian WRT, Phonegap etc.
>
> So, once again, what should DAP standardize? Are W3C now ready to  
> take the step towards a full "REST approach" or should we for now  
> stick to pure JS APIs and see the REST level as a future step?
>
> If we do not specify the REST level will this happen anyway in a  
> "non-W3C manner"?
>
> As a conclusion I would give a precautious support for a REST  
> approach, at least for the APIs where it can bring added value,  
> e.g. for services that can reside in the device as well in the  
> network (Calendar, Tasks, Contacts, and Gallery as suggested by  
> Robin). However, the question is whether we should switch to a REST  
> level approach now or whether we should keep the pure JS track and  
> consider the REST level as a next step.
>
> Your humble
>   Claes
>
>
>> -----Original Message-----
>> From: public-device-apis-request@w3.org [mailto:public-device-apis-
>> request@w3.org] On Behalf Of Arve Bersvendsen
>> Sent: tisdag den 2 februari 2010 09:07
>> To: Max Froumentin; Robin Berjon
>> Cc: public-device-apis@w3.org
>> Subject: 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 Wednesday, 10 February 2010 11:50:13 UTC