- From: Mounir Lamouri <mounir@lamouri.fr>
- Date: Tue, 04 Oct 2011 16:55:37 +0200
- To: public-device-status@w3.org
- CC: Jonas Sicking <jonas@sicking.cc>
Hi, As part of the WebAPI effort at Mozilla [1], we did write a draft implementation of something we are calling Battery API [2] (inspired by the Battery Status Events). Those two specifications are close and we would like to give some feedback on the changes we did and the changes we might want to discuss. The major change we did is actually making the API synchronous: the BatteryManager object has a few attributes that give the current state of the device's battery. The DAP specification requires to use an event handler to get those information but we believe there are use cases where a developer might just want to get some information at a given moment without caring about changes and this shouldn't be harder than reading an attribute. For example, a game might disable some features if the battery is low but these features will not magically appear during the game if the device is plugged, it might change between two levels instead. In addition, we changed the complex set of events to something more simple: every time an attribute is changed, an event is fired. That means, there are 'levelchange', 'chargingchange' and 'statuschange' events instead of the other four events that seem a bit odd to us. The event handler can then access to BatteryManager to get the new values. Furthermore, we are adding a 'mozBattery' attribute in window.navigator [3] instead of using a constructor [4]. This attribute could be 'null' if the device has no battery. It prevents returning some specific values for the attributes when there is actually no battery. One disadvantage is that there is no way to know if a battery is hot plugged. Finally, the Battery Status Events specification introduces a 'status' attribute that can be 'ok', 'low' or 'critical' our implementation keeps that but we might be tempted to remove it. Indeed, from where the thresholds should come from? The Battery Status Events specifications say it should be left to the implementation but how can the implementation set sensitive values? Do battery internally have a 'low' indicator? In addition, even if the UA set the thresholds, they might not fit what applications are expecting. In that case, we should probably allow those applications to set them. However, that would be very similar than just listening to level changes and put the very simple logic in the event handler. One solution would be to replace the 'plugged' ('charging' in our implementation) and 'status' attribute with a 'state' attribute that could be 'charging' or 'discharging' for the moment. So, the idea of this email is to give our feedback about the Battery Status Events specification and why there are some parts of it we don't like but we also want to know why those parts are like that. We believe those were the results of some discussions and we might be missing a lot. We are eagerly waiting for your feedbacks! [1] https://wiki.mozilla.org/WebAPI [2] https://wiki.mozilla.org/WebAPI/BatteryAPI [3] Ideally, that should be window.navigator.devices [4] We are actually looking for large feedback about which pattern should be usually preferred. There are a few new APIs we are working on that use an object in navigator and some have a constructor. Thanks, -- Mounir
Received on Tuesday, 4 October 2011 14:56:03 UTC