W3C home > Mailing lists > Public > public-device-apis@w3.org > December 2010

Re: Comments on http://www.w3.org/TR/2010/WD-system-info-api-20100202/

From: Antoine Sanchez <ckkoshi@gmail.com>
Date: Fri, 17 Dec 2010 10:43:34 +0100
Message-ID: <AANLkTikwXaJkBCXe3uBrgVr0qWg75kTdA6q4NMbcC8Cf@mail.gmail.com>
To: Philip Gladstone <pgladstone@cisco.com>
Cc: public-device-apis@w3.org
Oh sorry I realize I didn't send to w3 but only to you.

I think you're right, future feature of device must be planed.

We should forward these emails to list non?

/toni

On Thu, Dec 16, 2010 at 2:48 PM, Philip Gladstone <pgladstone@cisco.com> wrote:
> Toni
>
> I don't have any particular view about what is an external source and
> what is an internal source. Thinking about more, I'm not sure that it
> really matters whether the source is internal or external. What matters
> is the timeRemaining, and (possibly) whether "things are getting
> better". I'm not sure how to define that.
>
> For example, on a desktop computer with an external UPS where the UPS is
> connected (probably via USB) to the computer, it would be useful to get
> the timeRemaining. I don't think that it really matters that the UPS is
> outside the physical box of the computer rather than inside the physical
> box. In both cases, there is a finite source of power.
>
> However, I will admit that there is, psychologically, something
> different about inside versus outside. On a cellphone, you can get these
> external battery packs to provide a charge -- typically they use primary
> (non rechargeable) AA batteries. This is a finite, external source.
>
> Maybe the model should deal with finite sources of energy and
> (effectively) infinite sources of energy (though the power may be
> limited). Thus, mains power, solar power, ambient enegry harvesting, are
> all infinite sources of energy, but have very different power levels.
> Everything else is finite -- batteries (rechargeable or not), energy
> storage flywheels, etc.
>
> Sorry about the stream of consciousness....
>
> Philip
>
> On 16-Dec-10 05:11, Antoine Sanchez wrote:
>> Yes you're right, it's difficult to report and use a good value.
>> Maybe constructor may set a "maxTimeRemaining" who will be the time
>> remaining when battery is in good life and fully charged.
>> And so we could use the "timeRemaining" to know how much battery left.
>> This way we are sure that value is a trustable value.
>>
>> About internal/external power, to me, internal power means just
>> battery, a desktop computer has only an external power (until you have
>> a uninterruptible power supply, but it is a battery).
>> But i think i see your point, do you mean we must not consider a brake
>> reloading as an external source, since it's not in a infinite power
>> source?
>>
>> /toni
>>
>>
>> On Thu, Dec 16, 2010 at 12:17 AM, Philip Gladstone <pgladstone@cisco.com> wrote:
>>> Thanks for this. With regard to the level, you could not report a number
>>> less than 0. However, most platforms start a shutdown process at some
>>> poinrt, and it seemed that that point was defined as zero. Given that
>>> the shutdown process can take some time (and power), what value do you
>>> want to report during the shutdown process? I think that the same is
>>> true for the maximal value. Most rechargeable batteries lose capacity
>>> over their life. Does this mean that, once the battery has lost 50% of
>>> its capacity, the value never reaches above 0.5? Or is it scaled on each
>>> charge cycle -- so that 1 means that the battery cannot be charged any
>>> more? NiMH batteries lose capacity when the temperature drops below
>>> freezing. Does this factor in? My main point is that, if applications
>>> are going to do sensible things with these values, then they need to
>>> understand what the values represent.
>>>
>>> Is it possible to charge without external power? It depends on your
>>> definition of internal stored energy. With the rise of ambient energy
>>> harvesting technology, it doesn't seem unlikely energy could be
>>> recovered from a spinning disk as it is spun down (think what your
>>> Toyota Prius does today when you apply your foot to the brake.....)  You
>>> may think that this is a corner case today, but I'm sure that a lot of
>>> people said the same about recovering energy during braking in the early
>>> days.
>>>
>>
>>
>>> Philip
>>>
>>> On 15-Dec-10 17:35, Antoine Sanchez wrote:
>>>> Hello,
>>>>
>>>> I'll just give an answer about 4.4.
>>>>
>>>> About level, I don't see the point why there's a negative value, 0 is
>>>> enough to say there's no more power, can you explain?
>>>>
>>>> I think if isExternal is false, there's no way that isCharging can be
>>>> nothing else than false.
>>>> If there's a solar charging, or even micro-wave charging, power source
>>>> will be external, not from battery.
>>>>
>>>> Thanks,
>>>> /toni
>>>>
>>>> On Wed, Dec 15, 2010 at 10:58 PM, Philip Gladstone <pgladstone@cisco.com> wrote:
>>>>> Hi
>>>>>
>>>>> I note the the StorageUnit property does not include flash memory. Since
>>>>> this is the most common sort of memory in phones (and probably in next years
>>>>> laptops in the form of SSDs), it seems a pity to use TYPE_UNKNOWN.
>>>>>
>>>>> I also have a philosophical objection to TYPE_UNKNOWN as it occurs in many
>>>>> places in this document. In some cases the type may really be unknown, but
>>>>> in most cases it is really TYPE_OTHER (such as the flash example). You may
>>>>> want to consider whether to add a TYPE_OTHER to each (effective)
>>>>> enumeration, or whether to define an extension mechanism to allow new
>>>>> technology to be adequately represented.
>>>>>
>>>>> In section 4.4 Power, it is clear that a very simple model of power is being
>>>>> assumed. It isn't obvious how you would fit an integrated solar charger for
>>>>> a cellphone (or e-book reader) into this model. When the sun is shining, is
>>>>> 'isExternal' true or false? Since the values of isCharging and isExternal
>>>>> have specific relationships, this gets complicated very quickly. If the
>>>>> solar charger was external, would this make a difference? I have seen
>>>>> laptops with fuel cells and batteries, and even one with a hand-crank.
>>>>>
>>>>> I would define the terms as follows;
>>>>>
>>>>> level of type float, readonly, nullable Specifies how much of the internal
>>>>> energy source remains, scaled as follows. A value of 0 means that the stored
>>>>> energy level is at a point where the system will enter shutdown mode, and 1
>>>>> indicates that the system's stored energy level is maximal. Negative values
>>>>> are only likely during the system shutdown process. Any threshold parameter
>>>>> used in a watch function to monitor this property applies to this attribute.
>>>>> No exceptions.
>>>>> timeRemaining of type unsigned long, readonly, nullable Represents the
>>>>> estimated time remaining in seconds before the system enters shutdown mode,
>>>>> based on net current power consumption (which may be averaged over a short
>>>>> period of time) and how much stored energy remains. If this value is null,
>>>>> this means that there is essentially infinite time remaining.
>>>>> No exceptions.
>>>>> isExternal of type boolean, readonly If true the device is currently
>>>>> receiving any power from an external source. If false the device is not
>>>>> receiving power from an external source.
>>>>> No exceptions.
>>>>> isCharging of type boolean, readonly Indicates whether the internal stored
>>>>> energy  level is currently increasing. If isExternal is false, this value is
>>>>> likely to be false, meaning that the system is consuming net positive power,
>>>>> and the stored energy source is therefore depleting.
>>>>> No exceptions.
>>>>>
>>>>>
>>>>> In the case of the section 4.7 Network, there seems to be an assumption that
>>>>> there is only a single connection to the network. This isn't the case for
>>>>> nearly all systems today. Also, with the advent of v6, each interface will
>>>>> have multiple ip addresses (probably at least one v4 address and probably at
>>>>> least two v6 addresses). This doesn't seem obviously representable in this
>>>>> schema.  Even if the interface was changed to return multiple Network
>>>>> property objects, it isn't clear whether it will return interfaces that are
>>>>> down. For example, would it return a TYPE_IEEE802_11 object if the Wifi was
>>>>> not currently associated to an access point (or a member of an adhoc
>>>>> network)? I suggest that having a way to enumerate the down interfaces will
>>>>> be useful. Further, there are logical interfaces such as VPNs or general
>>>>> tunnels as might be used in an I-WLAN implementation. It is not clear how to
>>>>> represent these. I also note that an application cannot tell what interface
>>>>> will be used for any particular network operation as it does not have access
>>>>> to the routing table. A use case might be to delay downloading large images
>>>>> while connected over GSM (and only show thumbnails) but show the full images
>>>>> if connected over 802_11. The problem is that the app cannot tell whether
>>>>> the connection to a particular data source will use GSM or 802_11. For
>>>>> example, if the 802_11 interface is associated to a public access point,
>>>>> there probably needs to be some sort of captive portal remediation before
>>>>> connectivity is established to the Internet. If the user chooses not to pay,
>>>>> then the connection will remain up at layer 2, but not able to communicate
>>>>> with the Internet.
>>>>>
>>>>> Thanks for reading this far...
>>>>>
>>>>> Philip
>>>>>
>>>>> --
>>>>> Philip Gladstone
>>>>> Distinguished Engineer
>>>>> Product Development
>>>>> pgladstone@cisco.com
>>>>> Phone: +1 978-ZEN-TOAD (+1 978 936 8623)
>>>>> Google: +1 978 800 1010
>>>>> Ham radio: N1DQ
>>>>> Blog: http://wwwin-blogs.cisco.com/pgladsto/
>>>>>
>>>>> Cisco.com - http://www.cisco.com
>>>>>
>>>>> This email may contain confidential and privileged material for the sole use
>>>>> of the intended recipient. Any review, use, distribution or disclosure by
>>>>> others is strictly prohibited. If you are not the intended recipient (or
>>>>> authorized to receive for the recipient), please contact the sender by reply
>>>>> email and delete all copies of this message.
>>>>>
>>>>> For corporate legal information go to:
>>>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>>>>>
>>> --
>>> Philip Gladstone
>>> Distinguished Engineer
>>> Product Development
>>> pgladstone@cisco.com
>>> Phone: +1 978-ZEN-TOAD (+1 978 936 8623)
>>> Google: +1 978 800 1010
>>> Ham radio: N1DQ
>>> Blog: http://wwwin-blogs.cisco.com/pgladsto/
>>>
>>> Cisco.com - http://www.cisco.com
>>>
>>> This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.
>>>
>>> For corporate legal information go to:
>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>>>
>>>
>
> --
> Philip Gladstone
> Distinguished Engineer
> Product Development
> pgladstone@cisco.com
> Phone: +1 978-ZEN-TOAD (+1 978 936 8623)
> Google: +1 978 800 1010
> Ham radio: N1DQ
> Blog: http://wwwin-blogs.cisco.com/pgladsto/
>
> Cisco.com - http://www.cisco.com
>
> This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.
>
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>
>
Received on Friday, 17 December 2010 09:44:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:15 GMT