Offline Applications

I sent mail to Yves and Robin soliciting comments on some thoughts Offline applications.
Here is the body of the note incorporating Yves' comments.  I was hoping to get comments
from Robin but am sending now in case we want to discuss on tomorrow's call.

=========================================

We agreed in previous discussions that AppCache is not suitable for running offline applications.So, I thought, why don’t we think about what we need to support offline apps.Here are a few ideas.Please comment.We can add more detail if this seems like a good direction.

The suggestions below recommend starting a new effort to support offline apps.I don’t know if this is within the purview of the TAG.

User Control

The user should be able to decide whether to run the application on connected or in offline mode.Even if the user is connected she may want to run in offline mode for performance, privacy or other reasons.

The user should also be able to decide when to synchronize if connected.In some cases, semantic conflicts can occur in the process of synchronization.The user should be provided option as to how these should be handled.Some of the options will be application-specific.If not connected, a list of updates must be stored locally and applied when she connects.The granularity of the list of updates is up to the appl as it can be in an all-or-nothing or in update-as-much mode.

When the application ends the user should be able to save the local database or delete it to conserve space (clear cached content).If she deletes it, the application cannot be started in offline mode but the user can start in connected mode and then go offline.

When the application starts and the user has a local copy of the database she must decide whether to use the local copy or, if connected, refresh from the global database.There are some options here that need to be spelled out carefully.

Synchronization

Synchronization is hard.This is why many apps get it wrong and people express frustration with bugs in the synchronization process.The really hard usecase here is when you try and synchronize and there are semantic conflicts.For example, someone else has updated the same item.Most semantic conflicts must be kicked back to the application for resolution by the user.Doing this in a graceful manner is difficult.

I have a radical suggestion here.Apps should, as far as possible, use off-the-shelf synchronization software.If you use a Relational database for local storage and a Relational database there are many third-party synchronization packages.(A JavaScript interface to SQL would be useful).If you want to use a NoSQL database for performance reasons then the choice is more limited but third-party synchronization packages are available for some of the more popular NoSQL databases.

I can provide references for synchronization packages and I can also detail usecases for synchronization if we decide to go in this direction.


-- 
All the best, Ashok