On Wed, Dec 31, 2014 at 10:47 AM, Jonas Sicking <[email protected]> wrote: > 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.
This can be solved if we write the pref to disk before calling the hardware, and revert it if the hardware fail to fulfill the request. The behavior can be kept internally to API implementations. > 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? This proposal is deliberately flawed to work with broken hardware. Instead of quietly trying to call the hardware for the user (before and after the reboot), the proposal is trying to be explicit to user when hardware fail to fulfill the request(s). > 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. > The proposal is designed such that "desired state" and "hardware state" is kept in sync as closely as possible, streamlining the interfaces between three. What you are describing is what we are doing right now -- keeping the desired state in mozSettings and have the API to track the changes and try to achieve the described hardware state. It's proven to be complex for both Gecko and Gaia, when the user attempt to toggle many times in a short interval -- something fairly common being tried by QA forks. I) For Gecko, since there is no way to deny changes in desired state, it would always have to "catch up" with the changes, presumably by queue the state change and send the requests to hardware one-by-one. II) For Gaia, we would have hard time to find the right timing for disabling/re-enabling the UI (to express the "working" state and provide a "cool down" period). Oh, and doing that on all toggles of the same setting on different apps. > 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. > Exactly. There is one even simpler alternative: We drop the UI requirement of (II) and ensure every Gecko API have (I) properly implemented. But then we will get bugs like "I am able to toggle 'airplane mode' 5 times in 1 sec but the icon only shows up after 1 minute." and we would have to argue that it's not a bug :) > 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
