Re: Pre-LC Review Requested: System Information API

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 14:47:45 UTC