2 messages in com.googlegroups.google-gearsRe: Value in a Background Sync Service?
FromSent OnAttachments
Eric Farrar10 Sep 2007 12:51 
Eric Farrar10 Sep 2007 13:17 
Subject:Re: Value in a Background Sync Service?
From:Eric Farrar (iany@gmail.com)
Date:09/10/2007 01:17:41 PM
List:com.googlegroups.google-gears

I didn't notice the thead "What about bookmarklets for easy going offline and online" [http://groups.google.com/group/google-gears/ browse_thread/thread/ddc40b2751e313ad] until after I had posted. This would seem to be an extension of the ideas mentioned there.

It is generally agreed that for a web application that is intendeds to go offline, it is much better if the system can automatically prepare to go offline rather than the user expressly pressing a "go offline" button. This provides a much better user experience because the user may not always know when they are going to be going offline.

But, this still requires that the application was opened recently. Suppose that while on a plane you find you need an application (that has offline capability) that you haven't opened in a week. Whatever synchronization logic you have will not have been run since the last time you used the application.

What about the idea of automatically synchronizing your offline applications even when you aren't using them? One way you could do this is to have something 'kick off' the synchronization (more on this later) that then walks through all your off-line databases and attempts to execute some file like 'doSync.js' if it exists in that app's resource store. Each application can choose to implement a "doSync.js" file if they wish.

As far as kicking off the sync process, it could either be a background service that actually gets installed when Gears is installed, or it could be a button in the Google Gears Settings dialog in the browser. The latter still requires that it be manually started, but you could sync all of your sites at the click of a button rather than visiting each one individually. Each 'doSync.js' could even reply with an error code and so you could see at a glance which ones succeeded and which didn't.

Since you would not be actually using the application, the user would have no role in resolving conflicts. But this shouldn't be a problem since users don't usually understand merge interfaces anyways. This seems to be echoed by the people at Dojo Offline Toolkit. In their 'Sync Guidelines" they advise, "...rather than showing merge interfaces when syncing, the client- or server-side should automatically make a best guess, without UI intervention by the user." [http:// docs.google.com/View?docid=dhkhksk4_8gdp9gr#sync]

Comments?