- From: Robin Berjon <robin@berjon.com>
- Date: Fri, 4 Feb 2011 16:52:32 +0100
- To: Paddy Byers <paddy@aplixcorp.com>
- Cc: "Nilsson, Claes1" <Claes1.Nilsson@sonyericsson.com>, Dominique Hazael-Massieux <dom@w3.org>, public-device-apis <public-device-apis@w3.org>, "Isberg, Anders" <Anders.Isberg@sonyericsson.com>, "Nord, Christian" <Christian.Nord@sonyericsson.com>, "Svensson, Magnus" <Magnus.Svensson@sonyericsson.com>
Hi Paddy, On Feb 4, 2011, at 16:16 , Paddy Byers wrote: > In BONDI (1.5, which never really become public) we formulated a generic sensor API, which dealt in a generic way with discovering available sensors of arbitrary type with sensor-specific description of capabilities, defining sensor-specific value types, reading sensor values, watching sensor values with a generic way to specify triggers or thresholds, etc. This seemed to be the minimum that you would want from a generic API. There was no way in the API to "configure" a sensor, but you could get a "parameterised" instance (ie specify some parameters when you get the sensor instance) and specify thresholds when watching for sensor changes. > > If it is of interest to the group I can dust it off and circulate it. Yes, I wanted to look for it (as well as the DLNA API that was there too) but all I can see to find from the BONDI web site are 404 pages these days. I don't know if the Membership will decide to add these to the charter, but it's certainly worth having something concrete to look at so that people can make their minds up. Comparison with a Web Introducer approach would be interesting (for both sensors and DLNA — and for DLNA I think there's also an OIPF API that might be worth looking, though to be honest DLNA/UPnP scares me, there are hardly any good reasons to use SOAP anywhere, but with embedded devices it seems profoundly wrong). -- Robin Berjon - http://berjon.com/
Received on Friday, 4 February 2011 15:53:05 UTC