- From: Arthur Barstow <art.barstow@nokia.com>
- Date: Fri, 22 Jan 2010 08:36:24 -0500
- To: ext Max Froumentin <maxfro@opera.com>
- Cc: public-device-apis <public-device-apis@w3.org>
Hi Max, On Jan 20, 2010, at 12:03 PM, ext Max Froumentin wrote: > 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. The priorities you state above are consistent with my expectations for the DAP WG. -Art Barstow
Received on Friday, 22 January 2010 13:37:36 UTC