RE: ACTION-16 for SystemInfo API

isExternal: based upon other comments, I agree to keep this, distinct. I think the key thing for apps is to know:
(1) how much battery is left
(2) do I have an alternate source (which "being charged" implies, but I agree there are corner cases in which this is not true)

Roaming: discussion continues in another branch of this thread. Maybe MCC/MNC will suffice, if we can determine the home and current MCC/MNC.

LTE reference: http://www.3gpp.org/article/lte

Long Term Evolution (LTE) focuses on enhancing the Universal Terrestrial Radio Access (UTRA) and optimizing 3GPP’s radio access architecture, with targets to have average user throughput of three- to four-times the Release 6 HSDPA levels in the Downlink (100Mbps), and two to three times the HSUPA levels in the Uplink (50Mbps).

More network info (available, supported, default, and preferred) will help applications determine when a network can/should be used, or to provide clear guidance to the user as needed (e.g. "Your device supports WiFi. This app will work better if you set your default connection to WiFi.") If we take the approach that these are properties that can be returned through the SystemInfo interface (rather than creating specific interfaces for them), then there should be no additional spec effort to include them. Certainly the "active" network is good to include at least if we are creating specific interfaces.

Thanks, 
Bryan Sullivan | AT&T
-----Original Message-----
From: Max Froumentin [mailto:maxfro@opera.com] 
Sent: Tuesday, February 23, 2010 5:26 AM
To: SULLIVAN, BRYAN L (ATTCINW)
Cc: public-device-apis@w3.org; public-uwa@w3.org
Subject: Re: ACTION-16 for SystemInfo API

Hi Bryan,

Thanks for your review. I'm looking forward to your analysis.
For now I'll just comment on the remarks below.

On 23/02/2010 10:12, SULLIVAN, BRYAN L (ATTCINW) wrote:

>
> Here are comments to the Power and Network properties.
>
> Power.level should be aligned with the DCO (hard:batteryLevel (0 to 100
> inclusive)).

Done. I've added an appendix to the draft with DCO mappings, which I'll 
complete as we go along.

> Power.isExternal is redundant with Power.isCharging. batteryBeingCharged
> (DCO hard:batteryBeingCharged) is a clearer name.

OK, I thought that isCharging was independent from isExternal, but I 
guess you can infer isExternal from batteryBeingCharged if you keep 
batteryBeingCharged to true even if the battery is fully charged.

> Power.timeRemaining is useful but should be described "Represents the
> estimated time remaining in seconds before the battery will be depleted,
> based upon current power usage. If batteryBeingCharged is true, this
> value must represent the estimated time remaining in seconds before the
> battery would be depleted, based upon current power usage, if external
> power were removed." It should also be added to the DCO
> (hard:batteryTimeRemaining).

ok. I've added an appendix with the mapping to the DCO.

> Network: add TYPE_LTE

Could you provide a short description, or ideally a reference?

> Overall, for network info the model provided by the DCO is more complete
> and contains additional useful info on networks that are active,
> available, supported, default, and preferred.

Yes, but do we need those? I had them at the beginning, but following 
our decision to simplify, I edited the spec down to only have active. 
Should we reconsider for this case?

> roaming should have three values: national, and international. If not
> roaming, the value should be null. This should also be added to the DCO
> (dcn:roaming).

national roaming: is that in some countries you could be roaming in the 
same country? Then is it important to differentiate between national and 
international roaming?

in order to properly have national and international, we should have 
constants in the interface (ROAMING_NATIONAL and ROAMING_INTERNATIONAL, 
say). Since there are already constants for connection type, there's a 
risk of collision. So we can either have:

DOMString? roaming; // "National", "International"

or

const unsigned short ROAMING_NATIONAL = 5000; //or some other bignum
const unsigned short ROAMING_INTERNATIONAL = 5001;
attribute RoamingType roaming;

or through a new interface for roaming:

...
attribute RoamingType roaming;
...

interface RoamingType {
   const unsigned short ROAMING_NATIONAL = 0;
   const unsigned short ROAMING_INTERNATIONAL = 1;
   attribute unsigned short type;
}


I like neither, but the third is the least bad, imo. What do you think?

Max.

Received on Monday, 1 March 2010 12:22:53 UTC