Current: Gaia app (e.g. Settings app) <--> mozSettings for hardware switch <--> Gecko pref
Proposed solution: Gaia app (e.g. Settings app) <--> API for hardware switch <--> Gecko pref Above is my understanding, is it correct? Maintaining two kinds of configuration for one purpose is an overhead. If the proposed solution is the right direction, should we consider all conditions than just hardware switches? For example, we have Gecko pref for proxy server, but they are not configurable by user on Firefox OS. To allow configuration by Gaia app, we can either: 1) create new API that directly accesses Gecko pref, or 2) create new mozSettings and maintain the mapping to Gecko pref. In such case, which way do we encourage to use? 2014-12-30 10:39 GMT+08:00 Tim Guan-tin Chien <[email protected]>: > TL;DR: I proposed all hardware API switches to not only move out of > mozSettings database, but also have the API taking it's own > responsibility to make the settings persistent, and expose the current > value and changes through the API. > > Hi, > > I would like to make sure we reach a consensus on we should deal with > hardware switches and it's relations with mozSettings. > > Back in FxOS v1.0 we made a mistake moving some hardware switches to > mozSettings, and it's problem to cause a lot of headaches. The boolean > in the settings is proven to be not enough to reflect the status of > API (e.g. is being enabled, or failed to be enabled) and a lot of bugs > was caused by this. People then was mostly agreed we should move the > switches back to the APIs, e.g. mozMobileConnection.setRadioEnabled() > and returns a Promise. > > Yet, once the switch has been move out of the API, we have not yet > decided what we should do with mozSettings. The settings is still > needed because we would like to keep the user preference persistent > across reboot (e.g. when the radio is turned on|off, it stay on|off > when the phone reboots). But then we have the problem who is > responsible of setting and getting these settings. > > 1. If we let the API caller (e.g. Settings app) to set the > mozSettings, we would have to do > > (A) in Settings app > mozMobileConnection.setRadioEnabled(val) > .then(function() { > return navigator.mozSettings.createLock().set( ... ); > }); > > and (B) in Systems app when the phone boots. > > navigator.mozMobileConnection.createLock().get( ... ) > .then(function(value) { > return mozTelephony.setRadioEnabled(value); > }); > > This is undesirable because > > 1. Not every API switch caller do (A) has access to mozSettings should > the API become privileged, and even if they do we can never sure they > have indeed updated the settings correctly. > 2. (B) currently contributes to phone boot-up time a lot, which is > documented in bug 1095034 ("Too much IndexedDB on startup"). > > So I talked to Hsinyi, Alive, and Arthur, and I come up with the proposal > and they agree: I propose the responsibility of keep the status should be > moved from Gaia to Gecko, specifically, each of the APIs should keep > their own status in a clean way, and simply remove the mozSettings key > altogether. The API can keep the value in Gecko pref, which we can > make sure the hardware status and the pref is always in sync, and Gaia > will take the value returned from API (a |getRadioEnabled| method for > example, or an |radioEnabled| property?) as a single source of truth. > We would also need the API to send a change event to all document when > the status changes. > > Thoughts and comments? Thanks. > > > Tim > _______________________________________________ > dev-webapi mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-webapi > -- Shian-Yow
_______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
