Re: Pre-LC Review Requested: System Information API

> There is some confusion on the meaning of internal and external, I
> realise. I should make it clearer what I meant:
> - internal means battery
> - external means AC
>
> 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?

This seems clearer and more straightforward.

regards, Frederick

Frederick Hirsch
Nokia



On May 11, 2010, at 10:47 AM, ext Max Froumentin wrote:

> On 10/05/2010 17:36, timeless wrote:
>
>>
>>>>> If both highThreshold and lowThreshold parameters are
>>>>> specified, the success callback is triggered if and only if the
>>>>> property value is either lower than the value of lowThreshold
>>>>> or higher than the value of highThreshold.
>>>> It's odd that you've stuck this into lowThreshold but not high
>>> What do you mean?
>>
>> == attribute double highThreshold This attribute has no effect on the
>> get() method. On the monitor() method, it indicates that the
>> successCallback is only be triggered if the property is a number and
>> its value is greater than or equal this number. attribute double
>> lowThreshold This attribute has no effect on the get method. On the
>> monitor() method, it indicates that the successCallback is only be
>> triggered if the property is a number and its value is lower than or
>> equal this number. If both highThreshold and lowThreshold parameters
>> are specified, the success callback is triggered if and only if the
>> property value is either lower than the value of lowThreshold or
>> higher than the value of highThreshold. ==
>>
>> That last sentence is only present in the description of the second
>> attribute.
>
>
> 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.
>
>>>>> Indicates whether the internal power source is currently
>>>>> charging. A value of true, indicates that the battery is being
>>>>> charged. If false then the battery is not being charged.
>>>> What if I have an external battery which is being charged?
>>> then both isExternal and batteryBeingCharged are true.
>>
>> The description says "internal power source is currently charging",
>> I'm offering to charge the external power source. I think you should
>> elide "internal".
>
> There is some confusion on the meaning of internal and external, I
> realise. I should make it clearer what I meant:
> - internal means battery
> - external means AC
>
> 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've looked for a reference that explained the meaning of all the
>>> terms that I considered, and failed to find one. Do you know if
>>> there is something out there that would indicate what those terms
>>> mean?
>>
>> Wikipedia's articles here don't seem particularly bad:
>> http://en.wikipedia.org/wiki/Load_(computing)
>> http://en.wikipedia.org/wiki/CPU_usage
>
> CPU usage redirects to CPU time, described as "The CPU time is often
> measured in clock ticks or as a percentage of the CPU capacity". The
> name "time" is rather inadequate, though, so let's go for usage then.
>
>>>> What if I'm using 2 or more connections concurrently?
>>> That's very advanced for this API. See previous discussions on this
>>> topic.
>>
>> Link please? :)
>
> 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.
> 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.
>
>
>>>> The VPN case worries me.
>>> Sorry to hear. Why?
>>
>> People are unlikely to be aware that exposing details of their vpn
>> connection is more interesting and potentially dangerous than just
>> exposing their network connection. I might be willing to provide the
>> connection details for my normal network connection, but corporate
>> policy probably doesn't want me to disclose my vpn's information.
>> Above you've specified that the UA can only disclose one, so which
>> does it pick (and how?).
>
> 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.
>
>
>>>> TYPE_BLUETOOTH?
>>> or IRDA, RS-232, USB, WAP, etc. I wasn't sure where to draw the
>>> line and include standards that define a whole protocol stack, or
>>> ones that merely act as tethering protocols, or ones that just
>>> encapsulate Ethernet. I'd very much welcome a comprehensive list.
>>
>> I'd kinda want the list to be based on properties (pulse based v
>> cable, power expensive, currency expensive, range [short, medium,
>> long]): USB is Cable+Minor+Free+Short. Ethernet is
>> Cable+Minor+Free+Medium. IRDA is Beam+Medium+Free+Short. Bluetooth is
>> Radio+Medium+Free+Short. GPRS is Radio+Expensive+Expensive+Medium.
>> WiMax is Radio+Expensive+Expensive+Long.
>>
>> People generally don't need to know the name, they need to know the
>> attribute (is it $0, is it power hungry, can I ask the user to shake
>> the screen, ...).
>
> 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, but listing mobile phone data
> network types (GPRS, EDGE, etc.) risks becoming quickly obsolete.
>
>>>> Or a UA defined type?
>>> As a free-form string? It's tricky because they're basically not
>>> usable.
>>
>> The contrast was to this: == attribute unsigned short code The code
>> attribute SHOULD contain one of the error values defined in this
>> specification. An implementation MAY define additional error codes,
>> but those MUST NOT use the numeric values defined here. ==
>
> 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?
>
>
>> Btw, I'd suggest that you reserve a certain range, either for
>> standards values or for UA values.
>>
>>>> This is not what I think about when I read RAM. I'd rather
>>>> "FLASH" even if it's terribly inaccurate.
>>> I'd rather something accurate, so any suggestion is welcome.
>>
>> My colleague here said "usually they'd call it Flash", so let's
>> pretend I didn't posit that it might be inaccurate.
>>
>> http://en.wikipedia.org/wiki/Flash_memory
>> seems to indicate that Flash is perfectly reasonable. "Not to be
>> confused with USB flash drive or Memory card" is funny, because:
>>> A memory card or flash card is an electronic flash memory data
>>> storage device used for storing digital contents.
>
> ok, changed.
>
>
>>>>> The number of image sensor elements (pixels) of this camera
>>>> This is a strange way to write what you're trying to say.
>>> What's a better way?
>>
>> Dunno, my problem is: http://en.wikipedia.org/wiki/Pixel#Megapixel
>>
>> == ... each sensor element can record the intensity of a single
>> primary color of light.... These sensor elements are often called
>> "pixels", even though they only record 1 channel (only red, or green,
>> or blue) of the final color image. ==
>>
>> The problem is that there's a 3x multiplier between "sensor
>> elements" and what I think you want ("pixels").
>>
>> This isn't my area, I'm just a parser.
>
> Mine neither. I've changed to "picture elements", which avoids the
> problem at the cost of making the definition kinda circular.
>
> Cheers,
> Max.
>
>

Received on Tuesday, 11 May 2010 17:04:15 UTC