- From: Frederick Hirsch <frederick.hirsch@nokia.com>
- Date: Sat, 23 Jan 2010 10:54:37 -0500
- To: ext Max Froumentin <maxfro@opera.com>
- Cc: Frederick Hirsch <frederick.hirsch@nokia.com>, Robin Berjon <robin@robineko.com>, "public-device-apis@w3.org" <public-device-apis@w3.org>
+1 regards, Frederick Frederick Hirsch Nokia 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 > API > 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