Just curious, would this be a non-issue if we stored more information than just a boolean? What if we stored additional information say, in JSON? Have we thought about using datastore?
As we've seen in the past moving stuff into gecko can be a slippery slope, so we should definitely think this out thoroughly. In any case, it seems that this might create a more friendly API for third party developers, so a +1 from me on that front. It does seem like a *lot* of work though. I think it'd be worth while to do an initial investigation on both a platform fix and a different store in gaia to make sure we invest our time wisely. Best, Kevin On Mon, Dec 29, 2014 at 9:39 PM, Tim Guan-tin Chien <[email protected]> wrote: > 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 >
_______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
