Re: Pre-LC Review Requested: System Information API

On 11/05/2010 23:41, timeless wrote:
> On Tue, May 11, 2010 at 5:47 PM, Max Froumentin<maxfro@opera.com>  wrote:
>> Ah, I see. It was the most logical place to put it. After both high and
>> low were defined, but not separate. I don't know if it's wise repeating
>> the same text in both places, either.
>
> I'm just flagging. I'm hoping someone else will have an opinion, or an
> example of precedent.
>
>> In that case we should remove internal/external terminology and define
>> attributes as:
>> - isBattery: true if the current power source is a battery
>> - isBeingCharged: true if the current power source is a battery and is
>> being charged
>>
>> What do you think?
>
> I'd prefer "isCharging", but otherwise, yes.

Done.

> and drop "current" from the descriptions.

Why? The power source can be changed over time.

>> For instance, we don't find a common use for exposing multiple CPUs and
>> their frequencies. The same principle applies here: how often does a
>> device use multiple internet connections?
>
>> Should it matter to the API user? I think that the answer is no.
>
> dunno. my n900 has a vpn regularly, the others at the office will
> often have WiFi + USB.

At the same time in the same application?

> It's likely that some n900s or similar will have both a GPRS network
> and an MMS network. Those are oddly enough distinct networks. And if
> an app wants to be an MMS sender, it actually needs to know that the
> MMS network exists and that it is different from the normal GPRS
> network. The IP addressing for GPRS and MMS can be entirely unrelated
> (it's a disaster, if you have some time for an amusing read, feel
> free).
>
> The MMS use case really is a use case. wrt apps which implement mms,
> for the n900, i'll point to fMMS. Note that in reality, MMS is
> basically a web app which uses web like protocols to send web like
> content.

but for MMS the application can use the Messaging API. I think it's 
confusing to see MMS withing the scope of Network.

>> It would be interesting to have those attributes, but I don't think it's
>> going to be what webapp developers will want. Adding Bluetooth, WiMax,
>> USB (or just Serial) seems acceptable,
>
> seems reasonable.
>
>> but listing mobile phone data
>> network types (GPRS, EDGE, etc.) risks becoming quickly obsolete.
>
> Oh, I'm suggesting offering the attributes w/o specifying the actual
> network names.

I'm still in 2 minds about PLMN. On the one hand we can't be exhaustive 
if we want to list GPRS, EVDO, GSM, etc., and on the other it's 
important to differentiate them (more than just comparing 
maxDownloadBandwidth, as I have suggested).

I think that I leaning towards the former now, but with string values
[[
attribute type;
one of "Wired", "WiFi", "Bluetooth", "GPRS", "GSM".
Updates of this specifications may standardise more string values. In 
the meantime vendors may define non-standard values, blah blah blah
]]

Max.

Received on Wednesday, 12 May 2010 09:36:00 UTC