On 11/05/2010 23:41, timeless wrote:
On Tue, May 11, 2010 at 5:47 PM, Max Froumentin<[email protected]> wrote:
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.
I'm just flagging. I'm hoping someone else will have an opinion, or an
example of precedent.
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'd prefer "isCharging", but otherwise, yes.
Done.
and drop "current" from the descriptions.
Why? The power source can be changed over time.
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.
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?
It's likely that some n900s or similar will have both a GPRS network
and an MMS network. Those are oddly enough distinct networks. And if
an app wants to be an MMS sender, it actually needs to know that the
MMS network exists and that it is different from the normal GPRS
network. The IP addressing for GPRS and MMS can be entirely unrelated
(it's a disaster, if you have some time for an amusing read, feel
free).
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.
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,
seems reasonable.
but listing mobile phone data
network types (GPRS, EDGE, etc.) risks becoming quickly obsolete.
Oh, I'm suggesting offering the attributes w/o specifying the actual
network names.
I'm still in 2 minds about PLMN. On the one hand we can't be exhaustive
if we want to list GPRS, EVDO, GSM, etc., and on the other it's
important to differentiate them (more than just comparing
maxDownloadBandwidth, as I have suggested).
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
]]
Max.
