RE: [SysInfo] Wiki Page and a proposal for the API structure

Hi,

You have done a good work collecting the different inputs. However I have several comments:

1) Regarding you separation between devices and properties I would be careful as sometimes I can need information about an specific input device, for example the active camera or the primary camera. The same can apply to other hardware elements. I think in this case the API has to be more sophisticated. For example in Bondi we defined well-known identifiers for components (aspect instances) in order to differentiate between them

2) I'm not sure that the sysinfo API is only concerned with hardware components but also with any other kind of component installed or related to the device which can be in an specific state. For example, is a network a hardware element? I don't think so. 

3) The properties you enumerate are useful but arbitrary in the sense that I can consider other properties as useful as the ones you are considering. My proposal is to define by consensus the DAP Core Vocabulary in the same way we in the DDWG we defined the DDR Core Vocabulary. This DAP Core Vocabulary would constitute the minimal agreement between the DAP members about what information should be exposed by the API at a minimum. However the API should be prepared for exposing properties coming from vocabularies provided by vendors or industry initiatives such as Bondi, Jil or others. 

In any case such DAP Core Vocabulary should have well-defined mappings with the DCO. 

Best Regards


-----Mensaje original-----
De: public-device-apis-request@w3.org [mailto:public-device-apis-request@w3.org] En nombre de Max Froumentin
Enviado el: jueves, 26 de noviembre de 2009 10:58
Para: public-device-apis@w3.org
Asunto: [SysInfo] Wiki Page and a proposal for the API structure

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 Friday, 27 November 2009 09:08:29 UTC