Comments on http://www.w3.org/TR/2010/WD-system-info-api-20100202/

Hi

I note the the StorageUnit property does not include flash memory. Since
this is the most common sort of memory in phones (and probably in next
years laptops in the form of SSDs), it seems a pity to use TYPE_UNKNOWN.

I also have a philosophical objection to TYPE_UNKNOWN as it occurs in
many places in this document. In some cases the type may really be
unknown, but in most cases it is really TYPE_OTHER (such as the flash
example). You may want to consider whether to add a TYPE_OTHER to each
(effective) enumeration, or whether to define an extension mechanism to
allow new technology to be adequately represented.

In section 4.4 Power, it is clear that a very simple model of power is
being assumed. It isn't obvious how you would fit an integrated solar
charger for a cellphone (or e-book reader) into this model. When the sun
is shining, is 'isExternal' true or false? Since the values of
isCharging and isExternal have specific relationships, this gets
complicated very quickly. If the solar charger was external, would this
make a difference? I have seen laptops with fuel cells and batteries,
and even one with a hand-crank.

I would define the terms as follows;

|level| of type float, readonly, nullable
    Specifies how much of the internal energy source remains, scaled as
    follows. A value of 0 means that the stored energy level is at a
    point where the system will enter shutdown mode, and 1 indicates
    that the system's stored energy level is maximal. Negative values
    are only likely during the system shutdown process. Any threshold
    parameter used in a watch function to monitor this property applies
    to this attribute.
    /No exceptions./

|timeRemaining| of type unsigned long, readonly, nullable
    Represents the estimated time remaining in seconds before the system
    enters shutdown mode, based on net current power consumption (which
    may be averaged over a short period of time) and how much stored
    energy remains. Ifthis valueis|null|, this means that there is
    essentially infinite time remaining.
    /No exceptions./

|isExternal| of type boolean, readonly
    If |true| the device is currently receiving any power from an
    external source. If |false| the device is not receiving power from
    an external source.
    /No exceptions./

|isCharging| of type boolean, readonly
    Indicates whether the internal stored energy  level is currently
    increasing. If isExternal is |false|, this valu//e is likely to
    be |false|, meaning that the system is consuming net positive power,
    and the stored energy source is therefore depleting.
    /No exceptions./



In the case of the section 4.7 Network, there seems to be an assumption
that there is only a single connection to the network. This isn't the
case for nearly all systems today. Also, with the advent of v6, each
interface will have multiple ip addresses (probably at least one v4
address and probably at least two v6 addresses). This doesn't seem
obviously representable in this schema.  Even if the interface was
changed to return multiple Network property objects, it isn't clear
whether it will return interfaces that are down. For example, would it
return a TYPE_IEEE802_11 object if the Wifi was not currently associated
to an access point (or a member of an adhoc network)? I suggest that
having a way to enumerate the down interfaces will be useful. Further,
there are logical interfaces such as VPNs or general tunnels as might be
used in an I-WLAN implementation. It is not clear how to represent
these. I also note that an application cannot tell what interface will
be used for any particular network operation as it does not have access
to the routing table. A use case might be to delay downloading large
images while connected over GSM (and only show thumbnails) but show the
full images if connected over 802_11. The problem is that the app cannot
tell whether the connection to a particular data source will use GSM or
802_11. For example, if the 802_11 interface is associated to a public
access point, there probably needs to be some sort of captive portal
remediation before connectivity is established to the Internet. If the
user chooses not to pay, then the connection will remain up at layer 2,
but not able to communicate with the Internet.

Thanks for reading this far...

Philip

-- 
Philip Gladstone
Distinguished Engineer
Product Development
pgladstone@cisco.com
Phone: +1 978-ZEN-TOAD (+1 978 936 8623)
Google: +1 978 800 1010
Ham radio: N1DQ
Blog: http://wwwin-blogs.cisco.com/pgladsto/

Cisco.com - http://www.cisco.com

This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

Received on Wednesday, 15 December 2010 21:59:12 UTC