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-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g
