Re: Power states

Hi Bruce,

On 23. Feb 2024, at 7.24, Bruce Nordman <bnordman@lbl.gov> wrote:

Devices and Sensors Working Group--
  Greetings. I have followed this list for several years but have not contributed at all recently or at all.
  I see that the current scope includes power status and power state transitions for the screen and device.
  I have worked on communication protocols related to power state and wrote an IEEE standard (1621) on how power state information should be presented to people. I have worked on test procedures and energy efficiency specifications about power states, and worked on various standards that include power states in multiple standards organizations.
  I would welcome a discussion (zoom?) on power state terminology. I hope someone can provide me guidance on how best to contribute.
  For substance, some key conclusions are:
-There are three basic power states: On, Sleep, Off
-Avoid the term Standby - it is inherently unambiguous and untethered to any particular meaning
-Basic states can have substrates
-Devices only exit a power state with a power control (on the device, over the network, or an internal timer); devices may wake from sleep for many reasons

Thank you for your participation and comments. Your expertise in protocols and standards related to energy efficiency and power states is an asset to this group. These topics are becoming increasingly more important to help web developers create more sustainable web apps and experiences. For context, I believe you’re referring to these lines in the scope section of the charter:

[[

- reacting to device power status
- preventing the screen from turning off under certain conditions
- preventing the system from turning off under certain conditions

https://www.w3.org/2024/02/das-wg-charter.html#scope

]]

The following deliverables of this WG fall in this scope:

Battery Status API
Screen Wake Lock API
System Wake Lock API (not actively worked on, awaits implementer interest)
Compute Pressure API

All these APIs could benefit from improved terminology. You’ll find links to these specifications and their respective GitHub repositories from the WG’s roadmap page:

https://www.w3.org/das/roadmap


On how to best contribute in this WG:

This WG primarily conducts its work on GitHub in an asynchronous fashion. We organise teleconferences to discuss topic-specific issues only infrequently but have always met at the annual W3C TPAC offering both virtual and F2F attendance options. This year, we’ll likely meet again during the week of 23-27 Sep in Anaheim, CA, USA.

Please review the APIs mentioned above and if you have any suggestions for improvements please do not hesitate to file a new GH issue via respective spec GitHub repository issue tracker to allow for the most efficient collaboration. Concrete contributions are welcome via GH pull requests too. It is worth mentioning this mailing list has been used for announcements and weekly GitHub digests only for the last few years and active technical discussion on the group’s deliverables now happens solely via GitHub. Earlier before GitHub became a thing we did use this mailing list for technical discussions too. Those older discussions are archived at: https://lists.w3.org/Archives/Public/public-device-apis/


We look forward to your contributions to help improve the group's specifications. You’re also welcome to attend our future meetings.

Thanks,

-Anssi (DAS WG co-chair)