- From: Thomas Roessler <tlr@w3.org>
- Date: Wed, 10 Feb 2010 13:58:46 +0100
- To: "Anne van Kesteren" <annevk@opera.com>
- Cc: Thomas Roessler <tlr@w3.org>, "Nilsson, Claes1" <Claes1.Nilsson@sonyericsson.com>, "Frederick Hirsch" <Frederick.Hirsch@nokia.com>, "ext Ian Hickson" <ian@hixie.ch>, "public-device-apis@w3.org" <public-device-apis@w3.org>
That browser involvement could be extremely lightweight: E.g., you could have an object that returns a collection of (possibly http) URIs for each class of API that the script asks for. How these APIs are then implemented (browser involvement or not) would be entirely up to the specific implementation. -- Thomas Roessler, W3C <tlr@w3.org> On 10 Feb 2010, at 13:55, Anne van Kesteren wrote: > On Wed, 10 Feb 2010 13:52:40 +0100, Nilsson, Claes1 <Claes1.Nilsson@sonyericsson.com> wrote: >> Yes, there are different implementation alternatives. However, with a REST approach it is possible to implement "device APIs" through a local (downloadable) server. This opens up for API extensibility. > > Maybe. I think you still need some amount of browser involvement to let the user associate services with the URI the API evolves around and indicate which other services may access the data. > > > -- > Anne van Kesteren > http://annevankesteren.nl/ > >
Received on Wednesday, 10 February 2010 12:58:55 UTC