- From: Rich Tibbett <richt@opera.com>
- Date: Thu, 13 Oct 2011 11:08:47 +0200
- To: Bryan Sullivan <blsaws@gmail.com>
- CC: "Nilsson, Claes1" <Claes1.Nilsson@sonyericsson.com>, JOSE MANUEL CANTERA FONSECA <jmcf@tid.es>, "public-device-apis@w3.org" <public-device-apis@w3.org>, "Isberg, Anders" <Anders.Isberg@sonyericsson.com>
Bryan Sullivan wrote: > I suggest that we use two approaches to inclusion of external sensors: > - if the user agent has visibility to external sensors due to device > capability to discover them, it can expose them through the API > - we need to consider a general purpose in-network service discovery > capability for which sensor API can be one of the services, like other > APIs Given the Networked Service Discovery and Messaginge API proposal [1], if the OS or _any_ other process running on a machine advertises their own service type over SSDP or DNS-SD and that service then exposes access to sensor information via HTTP then we can accomplish this, right? Your proposal with our proposed Discovery API works for accessing any data-based information from a device - contacts, calendar, system information, sensors, app data, etc. It immediately reduces the problem to one of designing suitable HTTP-based APIs for whatever intended purpose you may have without requiring centralized standardization - or even collaborative design - of those interfaces up-front. Service types naturally form around interface designs which can then be implemented by multiple parties to create a psuedo-standard for whatever type of data you want to expose. If others don't like it they can simply choose a different service type, design a competing API and launch that. The process repeats until we get defacto-standard APIs for different device data. - Rich [1] http://people.opera.com/richt/release/specs/discovery/Overview.html
Received on Thursday, 13 October 2011 09:09:29 UTC