於 2014年12月30日 於 下午12:18:26, Kevin Grandon ([email protected]) 寫: 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? I think the problem is the race. You won’t know how long the datastore/settings db will callback, and the callback from enabling to enabled really does not mean navigator.HARDWARE.status is ‘enabled’ because the database operation is async and anything could happen during the database observer operation.
But if the hardware API has status change event we could make sure we always have the correct status in the callback. 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
