Re: Pre-LC Review Requested: System Information API

On Wed, May 12, 2010 at 12:35 PM, Max Froumentin <maxfro@opera.com> wrote:
>>> - isBattery: true if the current power source is a battery
>>> - isBeingCharged: true if the current power source is a battery and is

>> and drop "current" from the descriptions.
>
> Why? The power source can be changed over time.

batteries=getBatteries();
battery0=batteries[0];
battery1=batteries[1];
---
battery0.isBattery == true;
battery1.isBattery == true;

battery0.isCharging == true;
battery1.isCharging == true;
---

Here we have two batteries, both are charging. "current" here adds nothing.

A property "isCharging" naturally applies to the object of which it is
a property (battery0 or battery1), the batteries are both "current"
since they came from batteries[].

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

I think we're going to get in trouble with the definition of "application".

My browser will certainly have some traffic which wants to go over the
VPN and some traffic which will want not to go over the vpn.

Oddly enough, while i'm at work, I'll have a web app where the
authentication bits will somehow come from the office side and then
somehow want to connect me to an application outside our intranet.

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

In the case of fMMS, there *was* no Messaging API, the poor guy had to
write his own (presumably using http). He's a real use case, he added
something because the platform was perhaps arguably deficient. The
platform had chosen not to include a feature. The platform is also
fully capable of shipping a deficient feature implementation which
someone needs to replace...

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

I'm sure someone will someday curse me for having to guess the case of
the strings.

Received on Thursday, 13 May 2010 05:53:01 UTC