RE: ACTION-16 for SystemInfo API

The key distinction for roaming is the potential cost to the user. The major differences occur when the user is roaming internationally, although there may be a differential (usually less) when the user is roaming nationally (meaning different service providers within the same country of the user's home service). So we have used these two enumeration values in OMA for example, as the basic level of distinction. 

But if the same information can be derived from MCC and MNC (which presumably it can), then I agree a Boolean will suffice for roaming. But we need to be sure that the MCC/MNC (home and visiting) are things that the application can determine through the SysInfo API.

Thanks, 
Bryan Sullivan | AT&T


-----Original Message-----
From: Rotan Hanrahan [mailto:rotan.hanrahan@mobileaware.com] 
Sent: Tuesday, February 23, 2010 5:43 AM
To: Max Froumentin; SULLIVAN, BRYAN L (ATTCINW)
Cc: public-device-apis@w3.org; public-uwa@w3.org
Subject: RE: ACTION-16 for SystemInfo API

>> 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?

Actually, there are other classifications of roaming (including regional and trans-standards, (iirc)) and there are cases where the roaming is defined in terms of (political) geography, and other cases where the boundaries are defined by the network itself. For this reason, I don't think any of the proposals are suitable, and a bit more research is required.

---Rotan.

-----Original Message-----
From: public-uwa-request@w3.org [mailto:public-uwa-request@w3.org] On Behalf Of Max Froumentin
Sent: 23 February 2010 13:26
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 11:28:25 UTC