- From: Max Froumentin <maxfro@opera.com>
- Date: Thu, 26 Nov 2009 10:58:01 +0100
- To: "public-device-apis@w3.org" <public-device-apis@w3.org>
Hi,
I have gathered notes on the system information API at
<http://www.w3.org/2009/dap/wiki/SysInfo>. The page includes current
proposals, notes, as well as a survey of existing similar APIs. It's a
bit of a hodge-podge, but hopefully useful.
Second, I would like to offer a model for organising the SysInfo APIs.
It is based on the fact that there are 2 types of information that these
APIs would cover: hardware availability (e.g. this device has a Brand X
microphone) and sensor values (e.g. the current ambient noise level is
67 dB). The idea is to separate the first out into a "hardware
availability" API:
* Hardware availability: location/position, network, battery, input
device, audio, screen, etc.
and
* Variable properties (readable, watchable, possibly writable):
o Battery: number of, levels
o CPU, including fans and temperature
o Network level and type (GPRS, Wi-Fi, etc.)
o Storage: capacity, type (RAM, HD, etc.)
o Ambient Sound/Light/Temperature, Atmospheric pressure,
humidity, proximity to my face.
o Vibrator
o Position (lat/lon/orientation): covered by geolocation
(Possibly more, but that's not the point of this proposal.)
One may argue that this separation spreads the information returned by
each device over 2 APIs. Fair enough, however:
- programmers will most often need the values and not the means of
acquiring them (e.g. I want to trigger vibration, but I don't care how
many RPMs the vibraor throttles at)
- the existing geolocation API is not concerned about devices, and I
think that that API is a good model to follow and remain compatible with.
Your thoughts are welcome. In case of agreement or not-botheredness I
would like to start implementing this model in the draft soon.
Cheers,
Max.
Received on Thursday, 26 November 2009 09:58:41 UTC