On Mon, Dec 29, 2014 at 11:42 PM, Tim Guan-tin Chien <[email protected]> wrote: > I just talk to Hsin-Yi offline and I would like to make some > clarification here, by means of describing steps to run when the said > method is called: > > A. Steps to do when setFooEnabled(false) is called: > > 1. If the state is not "enabled", reject the promise and stop. > 2. If not, switch the property to "disabling". > 2. Dispatch a property change event. > 3. Submit the disable request to the relevant hardware. > 4. If the request is fulfilled by the hardware, > 4.1 Switch the property to "disabled". > 4.2 Set the persistent state to "disabled". > 4.3 Dispatch a property change event. > 4.4 Resolve the promise. > 5. If the request is rejected by the hardware, > 5.1 Switch the property back to "enabled". > 5.2 Dispatch a property change event. > 5.3 Reject the promise. > > B. Steps to do when the phone boots: > > 1. The state should start with "disabled". > 2. If the persistent state is "enabled", run steps as if > |setFooEnabled(true)| is called. > > The important thing to clarify is section A point 4.2: Persistent > state (e.g. Gecko pref) should not change if the request to hardware > is rejected -- therefore, a failed setFooEnabled() call should not > result any side effect.
As a user, I'm not sure that this is the behavior that I want. The most simple scenario is if I turn off wifi, but the phone crashes before the wifi radio has been fully shut down, I think I'd prefer that the wifi was off after bootup. A slightly more complex scenario is if I turn on wifi, but for some reason wifi fails to turn on, do I really want the phone to give up rather than try again? Especially after a reboot which might actually fix some broken state in the wifi driver? This scenario is a more complex though since I don't know under what circumstances wifi would actually fail to turn on? One possible solution is to separate "desired state" from "hardware state". So when setFooEnabled(true) is called, we'd immediately save the new value in prefs, and then reflect "enabled" in a "desired state" property. But the "hardware state" property would behave as you describe above and would switch to "enabling". If turning the hardware on fails, the "hardware state" would switch back to "disabled". However the "desired state" would still reflect "enabled". The API could then retry to turn on the hardware if that's appropriate. If we did this we could technically still use mozSettings to track the "desired state", and the individual API to track the "hardware state". But that might just make for a more complex API. But might mean smaller changes compared to what we have now. I do agree that this is a more complex system though. And one that requires UI authors to deal with more state and more complexity. So I'm happy to go with what you are proposing if people think that makes everyone's life simpler. / Jonas _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
