W3C home > Mailing lists > Public > public-device-apis@w3.org > October 2009

RE: ISSUE-14: Gathering requirements [System Info & Events]

From: Nilsson, Claes1 <Claes1.Nilsson@sonyericsson.com>
Date: Tue, 6 Oct 2009 10:43:35 +0200
To: "'Tran, Dzung D'" <dzung.d.tran@intel.com>, "Jere.Kapyaho@nokia.com" <Jere.Kapyaho@nokia.com>, "robin@robineko.com" <robin@robineko.com>, "jmcf@tid.es" <jmcf@tid.es>
CC: "public-device-apis@w3.org" <public-device-apis@w3.org>
Message-ID: <6DFA1B20D858A14488A66D6EEDF26AA3208923CDDE@seldmbx03.corpusers.net>
Thanks Jere for pointing at the earlier threads about sensors.

I agree that it will be difficult to specify a unique API for each type of sensor and that some kind of "generic" sensor API makes sense. That was what I meant by "universality".

Regards
  Claes

-----Original Message-----
From: Tran, Dzung D [mailto:dzung.d.tran@intel.com] 
Sent: måndag den 5 oktober 2009 18:34
To: Jere.Kapyaho@nokia.com; Nilsson, Claes1; robin@robineko.com; jmcf@tid.es
Cc: public-device-apis@w3.org
Subject: RE: ISSUE-14: Gathering requirements [System Info & Events]

It would be difficult to cover all the sensors ever made here, since new sensors come out all the time. Also, Geolocation is already a separate API and I consider Geolocation (GPS) is a sensor. I don't think it makes sense to have an API for each of type of sensor. 

Maybe a separate overall sensor APIs makes sense?


-----Original Message-----
From: Jere.Kapyaho@nokia.com [mailto:Jere.Kapyaho@nokia.com] 
Sent: Monday, October 05, 2009 06:00 AM
To: Claes1.Nilsson@sonyericsson.com; robin@robineko.com; jmcf@tid.es
Cc: Tran, Dzung D; public-device-apis@w3.org
Subject: Re: ISSUE-14: Gathering requirements [System Info & Events]

On 5.10.2009 15.46, "ext Nilsson, Claes1" <Claes1.Nilsson@sonyericsson.com>
wrote:
> I don't know if I am walking out of scope but I am considering "Personal
> Metrics" within training and healthcare. For example we have personal pulse
> watches, blood sugar sensors and blood pressure sensors. Web application
> access to measurement data from that type of devices, either "built in" or
> communicating with the device is needed. I guess that we can't predict all
> types of information that we need to access so some kind of "universality"
> would be useful within this context.

I think the operative word here is definitely "sensors", but thinking about
it, I would keep APIs related to system information and related events
separate from sensor input. I know that the lines tend to blur there, and I
have certainly had many debates as to whether the battery charge indicator
is a "sensor" just as an accelerometer (to give just a quick example). It
depends on your view of the world, I guess. :-)

There's a start of a thread about sensors [1], and I know Robin cautiously
opined [2] earlier that such would fit under System Information and Events.
This could be the beginning of an interesting (and long, and maybe
unnecessary) philosophical discussion, but in practical terms I'm simply
concerned about lumping sensors with system events. From a developer's point
of view a dedicated API for sensor data would probably be more palatable.

The argument for "universality" in API structure applies here as well as
with system events, of course.

--Jere

[1] http://lists.w3.org/Archives/Public/public-device-apis/2009Aug/0049.html
[2] http://lists.w3.org/Archives/Public/public-device-apis/2009Aug/0078.html
Received on Tuesday, 6 October 2009 08:44:17 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:39 UTC