On Tue, Dec 30, 2014 at 12:40 PM, Shian-Yow Wu <[email protected]> wrote: > 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?
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? The problem with (1) (or (2), which is the current solution), is that it is always susceptible to race unless proven otherwise. With a simple write op to pref or settings, caller do not know when Gecko will apply that config, or to respond when the setting failed to apply. The hardware switches are the most obvious cases, but I suspect almost every other cases are affected. On Tue, Dec 30, 2014 at 12:18 PM, Kevin Grandon <[email protected]> wrote: > 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? > The other approach, not mentioned on the original e-mail, is to tie the mozSettings even closer to the API, which allow the API to participate in the db lock and reject the changes when it fail to apply. I suspect there will be complex settings that would need this, but I object enabling mozSettings to do this for all APIs in general. > 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. > Yes, the efforts are non-trival. But this is one of the underlining issues preventing FxOS to be a stable platform. I am all ears for solutions to the problem that could solve this cheaply -- and I want to make sure new API does not repeat the mistake we already made. _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
