On 08/15/2013 02:14 AM, James Lal wrote:
> mind explaining this to me (or better in a comment) the "wifi" lock 
> will go to sleep fairly aggressively.
>
> This is was a particular fun calendar bug under slow wifi connections 
> because we could not complete the entire stack of network requests 
> that we started (<10s of requests).
>

The general idea from our IRC conversation was that getting this right 
is more complex than is worth pursuing in this initial landing and we 
should file a follow-up bug which we will absolutely try and work in 
v1.2.  Possibly parallelizing.  You sound interested in dealing with 
this!  Sucker!

Right now, if we acquire the 'wifi' wake-lock from our background sync 
and wi-fi was off (because we were on battery), this will cause the 
wi-fi to turn back on.  But our logic isn't waiting for the wi-fi 
connection to be established.  It's possible that by the time wi-fi 
comes up we will have already completed our sync.  If we wait for wi-fi 
to come up, it's possible that we aren't in range of a good wi-fi 
connection and that's wasteful.  Or maybe the resumed wi-fi connection 
will find us unable to actually reach the internet because we're on a 
wi-fi connection that requires user action to connect (ex: enter your 
hotel room number and name, code from the receipt, etc.)

The ideal goal would be to know if wi-fi was working recently and only 
turn it on in that case.  And/or be informed by some limited geofencing 
to know if there should now be different wi-fi networks in range that we 
should try and use.  The system wifi.js seems to set a settings flag for 
its own benefit that would tell us if wi-fi got powered down for 
wake-lock reasons so we could know whether we even bothered wanting to 
turn on the wi-fi.  A super built-out implementation would then know 
whether it wants to acquire the wake-lock, wait for something to happen, 
then store the results of that with the current cell tower id in use for 
geo-fencing purposes so next time around we know whether to try 
acquiring the wi-fi wake-lock again.

So the current cop-out lets us avoid the issue.  If the device is 
plugged in, wifi.js won't turn off the wi-fi, so we'll just be using 
wi-fi.  If the device is not plugged in, we'll just use the data 
connection.  This is acceptable for dogfooding by people with unlimited 
data plans, but is not a sufficient long term solution without more 
discussion.

We probably also need to think if we need to talk with UX or the 
settings app about stuff like this.  Such as adding a setting to 
ourselves like 'only sync over wi-fi'.