- From: Suresh Chitturi <schitturi@rim.com>
- Date: Mon, 17 May 2010 17:17:39 -0500
- To: <public-device-apis@w3.org>
- Message-ID: <D37CC1B151BD57489F4F89609F168FE805838211@XCH01DFW.rim.net>
Hi all, Here are a few comments (note some are purely editorial) to the current SysInfo draft. ==================== Abstract: Change: This specification defines an API to provide Web applications with access to various properties of the system on which they are running. Specifically, properties pertaining to the device hardware are exposed. Examples include battery status, current network bandwidth. Additionally, some of those properties offer access to the environment around the device, such as ambient brightness or atmospheric pressure. To: This specification defines an API to provide Web Applications with access to various properties of the system on which they are running. Specifically, properties pertaining to the device information are exposed. Examples of such properties include battery status, current network characteristics, and I/O properties. Additionally, some of those properties offer access to the environment around the device, such as ambient brightness or atmospheric pressure. 1. Introduction: Change: In order for web applications to gain access to information only available to an operating system's native applications, they must be able to access various data present on the device, either related to the hardware state (e.g. CPU usage), software data (e.g. pictures stored) or environment information (e.g. ambient brightness). The APIs defined by the Device APIs and Policy Working Group address this issue. Specifically, the API defined in this specification provides access to hardware devices, either internal (CPU, Thermometers) or ambient (light, noise or temperature). To: In order for Web Applications to gain access to information that is typically available to an operating system's native applications, they must be able to access various system properties on the device, either related to the hardware state (e.g. CPU usage), software data (e.g. storage capacity) or environment information (e.g. ambient brightness). The APIs defined by the Device APIs and Policy Working Group address this issue. Specifically, the API defined in this specification provides access to System Information and properties from the underlying platform related to Input/Output, AVCodecs, Network, Storage, Sensors, and other Internal device properties. The properties accessed through this API may be static and/or dynamic in nature. 4.1 System Properties A property is characterized by the following elements: * A name. * A URI, which is the concatenation of the string http://www.w3.org/2009/dap/SysInfo/ with the name of the property. * A webIDL [WEBIDL <http://dev.w3.org/2009/dap/system-info/#bib-WEBIDL> ] interface that contains its attributes. Comment: The 3rd bullet is mis-leading....I think what you mean really is that the interface is used to provides access to specific properties. I would rephrase it to the following for clarity: "A property is defined as a set of related device characteristics. For instance, the Power property contains all the characteristics that relate to the device's electrical power supply. Properties are accessible using the functions defined by the SystemInfo <http://dev.w3.org/2009/dap/system-info/#idl-def-SystemInfo> interface below. A property is characterized by the following: * A name. * A URI, which is the concatenation of the string http://www.w3.org/2009/dap/SysInfo/ with the name of the property. * A webIDL [WEBIDL <http://dev.w3.org/2009/dap/system-info/#bib-WEBIDL> ] interface that contains its attributes. The name of a property (or it's URI, interchangeably) is used in the functions of the SystemInfo <http://dev.w3.org/2009/dap/system-info/#idl-def-SystemInfo> interface to identify the accessed property. In response to calling one of those functions, the resulting property MUST be an instance of the property's interface i.e. an instance of webIDL [WEBIDL <http://dev.w3.org/2009/dap/system-info/#bib-WEBIDL> ] interface that contains its attributes." 4.2 The SystemInfo Properties Why is the following (i.e. get()) method a callback? I can understand the monitor() function which may be providing dynamic information. Having callback when it is not absolutely required can be annoying to the developer in terms of coding e.g. requiring mapping the callbacks to the calling function, etc. PendingOp get <http://dev.w3.org/2009/dap/system-info/#widl-SystemInfo-get> (DOMString propertyId, SuccessCB <http://dev.w3.org/2009/dap/system-info/#idl-def-SuccessCB> successCallback, optional ErrorCB <http://dev.w3.org/2009/dap/system-info/#idl-def-ErrorCB> ? errorCallback, optional Options <http://dev.w3.org/2009/dap/system-info/#idl-def-Options> options); I would be surprised if most of the properties (if not all) would be blocking if the user is trying to access properties with a one-shot approach. 4.7 Network There is an inconsistency with the property name "Network" and the interface name "NetworkAttributes" The same with Connection, CPU, Thermal, Sensors, etc. I understood we want to use the same name for properties as the interface name? Annex: For convenience to the developer/reader, it would be nice to have a table (like the example below) to describe all the property names and their mapping to the property interfaces. And reference this table from section 4.1. Property Name PropertyInterface System Information CPU CPUAttributes CPUAttributes.usage Power Power Attributes PowerAttributes.level PowerAttributes.timeRemaining PowerAttributes.isBattery PowerAttributes.isCharging ....... ....... ....... Regards, Suresh --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Received on Monday, 17 May 2010 22:33:49 UTC