RE: Rechartering Device APIs & Policy Working Group

Hi Robin,

+1 to looking into OIPF/CE-HTML for DLNA API.
DLNA works well in embedded devices.

Thanks,
Marcin

-----Original Message-----
From: public-device-apis-request@w3.org
[mailto:public-device-apis-request@w3.org] On Behalf Of Robin Berjon
Sent: Friday, February 04, 2011 4:53 PM
To: Paddy Byers
Cc: Nilsson, Claes1; Dominique Hazael-Massieux; public-device-apis;
Isberg, Anders; Nord, Christian; Svensson, Magnus
Subject: Re: Rechartering Device APIs & Policy Working Group

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 16:03:01 UTC