SysInfo
Notes on the System Information and Events API
Currently proposed requirements (Dzung)
- Power: battery(ies), wall
- Connection: WIFI, LAN, 3G, ..etc
- CPU: type, id#, model, freq, number
- Storage: hard disk, Solid state, read & write attributes, available space
- Memory: RAM,
- Display: # of display, color depth, resolution
- Input: mouse, keyboard, keypad, voice, stylus, multitouch, functions keys, command keys??
- Audio: stereo, 5.1, 7.1 channels, microphone (recording). Is this audio codec capability?
- Video: Is this video codec capability? What about recording?
- Thermal: internal, external (ambient)
- Ambient Sound
- Ambient Light (screen adjust due to brightness)
- Proximity
- Movement: gyroscope, accelerometer
- Vibrate device
- Compass, geolocation device
Currently Proposed Architecture
Max Froumentin 09:29, 26 November 2009 (UTC)
We choose to have 1 API for hardware presence/availability (all fixed properties) And several APIs for the various variables returned by the corresponding sensors/actuators, as such:
- Hardware devices availability: location/position, network, battery, input device, audio, screen, etc.
- Variable (read/watch, possibly write) properties. This list is not final
- Battery
- CPU, including fans and temperature
- Network level and type (GPRS, Wi-Fi, etc.)
- Storage: capacity, type (RAM, HD, etc.)
- Ambient Sound/Light/Temperature, Atmospheric pressure, humidity, proximity
- Vibrator
- Position (lat/lon/orientation): covered by geolocation
The alternative model is to have a module for each device that covers both availability and value. The reason is that we would like to remain as compatible as possible with the existing geolocation API which is concerned with location values, but not devices. Many applications will not care about how the properties are available, but only their value.
Existing APIs
W3C's DCCI
A DOM-like API to read, write or watch, a tree of device properties. Meant to be used with the Delivery Context Ontology of system properties. Another candidate is OMA's Device Profile Evolution's core vocabulary list (section 9.6).
Nokia's Sytem Info API contribution
- Charging
- Battery
- Network
- Signal Strength
- Phone Language
- Bluetooth
- Product Type
- Firmware Version
Bondi
The Bondi devicestatus module provides functions to get, set or watch properties identified by a URI or a local name. The list of properties is available separately, and maps to W3C's Delivery Context Ontology.
PhoneGap
- geolocation
- vibration
- accelerometer
- sound
- contacts
Opera Mobile DOM
- Contact list
- Messaging
- Todo-list
- Calendar events
- GPS positioning
- Launching native applications
- Network interface status
Joint Innovation Labs (JIL)
Requires registration and ToS agreement to download the SDK, but some information can be found in the forum.
Palm WebOS
The services API contains many interfaces covering most of this WG's scope. Pertinent to SysInfo are: Accelerometer, Connection Manager, Display Manager, GPS, Keys, Power Management, System Properties.
Netfront Browser Widgets
...
WebVM
Nokia's Javascript SystemInfo Service API
Firefox
Notes
There are 2 types of information that this API captures: the availability of system devices (and their type) and the data returned by it. For instance, through Sysinfo, one should be able to determine whether the device is running on batteries and if so what's the current level.
Note that for geolocation, the second aspect is covered by the existing Geolocation API, but not the first (since the existing API does not provide information about the device). A potential conflict exists, which might also be the case with other devices (File System vs. File I/O?)