- From: Giuseppe Pascale <giuseppep@opera.com>
- Date: Thu, 06 Oct 2011 15:59:51 +0200
- To: public-device-apis@w3.org, "Dave Raggett" <dsr@w3.org>
On Mon, 26 Sep 2011 16:59:48 +0200, Dave Raggett <dsr@w3.org> wrote: > On 26/09/11 07:57, N.V.Balaji wrote: >> Instead of providing a URL to access the service as with the >> getNetworkedServices proposal, the service object directly exposes the >> interface for accessing the service. >> >> [NVB]: That would mean that the interface JavaScript API should be >> defined for each service type. Pl. correct me if I am wrong. Given >> the enormity of this task (of defining APIs that can work over multiple >> protocols and >> implementing them) it is better that we go for a simpler approach, even >> if it is narrower in scope. > > This is an incremental process. We start with existing services and add > new ones as they are deployed.A simple solution for new services is to > use a generic interface that passes data as JSON. As one step beyond > that, I am looking at a means to automatically generate live interfaces > from JSON declarations, where the interface maps into a JSON RPC call. > This is all transparent to the web page script developer. In the longer > term, I would like to see an ecosystem where third parties provide > extensions for an increasingly wide range of devices and services. This > is particularly valuable for services where you need a service specific > driver, e.g. for many USB devices. If you have an API like the one we have proposed, could you do this in javascript, so to be transparent to the browser? It will be much easier for you to prototype in Javascript than having to modify the browser source or having to convince a browser manufacturer to support your service. /g -- Giuseppe Pascale TV & Connected Devices Opera Software
Received on Thursday, 6 October 2011 14:00:21 UTC