qgvdial does it's best to not update anything unless the user explicitly asks.
But then there is the issue of timely updates about new messages and calls - missed, received or otherwise. Google doesn't have a push api for this.
Why don't I just poll for it? Because polling means waking up every few seconds, opening a socket, sending a request, getting the data, parsing it, and then more times than not, figuring out that there is nothing new. This absolutely kills the battery life on the phone.
What I needed was a robust push mechanism.
This is where a qgvdial user - xur17 - suggested Mosquitto - a publish/subscribe message broker.
I've ported Mosquitto to Maemo and Diablo and added functionality to qgvdial to subscribe to a mosquitto topic to get inbox and contacts updates.
So now, qgvdial gets updates by just waiting (select) on a socket. No polling involved on the qgvdial side. All the heavy lifting and polling done on the publisher side, which resides in a place where there isn't any constraint on battery life or CPU consumption.
The publisher is a bunch of python scripts that continuously poll for changes in the GV inbox. On any changes, it publishes the change to the mosquitto server on the predefined topic.
This publisher can run on anything that has python. So any regular desktop OS would do. But I had another constraint: I wanted to energy footprint of the device to be as low as possible. What low power device do I have that I can afford to run continuously? I have 2: My DD-WRT router and the n810.
Right now, I've only run the scripts on the n810 and it turns out that this works pretty well to give me all the updates I wanted.
Pretty soon I'll attempt to make it all run even on the router so that I can really truly have only one device that is "always on", doesn't burn a lot of energy and still is a powerful enough machine to do everything I want.