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.




Reply via email to