- 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