Re: Pre-LC Review Requested: System Information API

[-webapps, -robin]

On 13/05/2010 07:52, timeless wrote:
> 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[].

We dropped the idea of multiple batteries, for the same reason as 
multiple active networks. This time I have a link:
http://lists.w3.org/Archives/Public/public-device-apis/2010Jan/0046.html

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

A bit far fetched, but I'll note the issue.

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

I've added the strings: Unknown, Ethernet, Wi-Fi, USB, WiMax, 2G, 3G, 
4G. I think that works ok.

Max.

Received on Friday, 14 May 2010 12:25:29 UTC