On Tue, Dec 30, 2014 at 1:29 PM, Tim Guan-tin Chien <[email protected]> wrote: > 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. >
Sorry, I should correct this one. I am not saying we should have a dedicated API for hardware switches, I am saying the given hardware API should provide the method to turn on/off given hardware, and the API should also keep the on/off state persistent by, for example, keeping the state in Gecko pref. >> 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
