Comments to Pre-LC Review: System Information API

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