Re: Pre-LC Review Requested: System Information API

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.
and drop "current" from the descriptions.

> The tracker is down at the moment, and I'm not sure what to look for in
> my email, but the group decided that we shouldn't put in the API
> features that we can't see used outside of a system monitoring context.

ok

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

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.

> That seems to be a good use case for policy rules, actually. I expect
> the policy framework comes up with would cater for this scenario.

ok

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

Of course, we have the problem of security grades where we once had
"high", "medium", and "low". Eventually "low" disappeared, and we
couldn't recalibrate.

> I'm a bit lost. You suggested that the type of network connection is a
> UA defined type, in constrast to a number, such as error codes? Can you
> elaborate on how it would work?

Oh, I wasn't suggesting, mostly poking at the contrast. If you use
attributes instead of names/numbers, then it's much less of a problem.

Received on Tuesday, 11 May 2010 21:42:20 UTC