Jim Panttaja

In the last week I have been looking at a couple of new development tools that support the occasionally connected user. I am particularly interested in these - because I am one of those users. When I am in my car, or on a plane, I still want to be able to do my work. But if I am using applications that require connectivity, I may be in trouble (I do have a portable router and cellular communication for my car - but I am not always in range).

Two of hese tools are, Apollo, and Google Gears. Both provide the ability to work with a local database on the client on the client machine when you are not connected. But neither address the design patterns required to manage synchronization between the client and the server.

A couple of examples of the design patterns are:

• An RSS feed client - that just views the current entries. When you next sync, overwrite any data on the client with the current data from the server.
• A data entry application - that allows users to add or edit data. But for a given data element, there is only one authorized writer/updater. When you next sync, overwrite any data on the server with the new client data. There are still potential conflicts - for instance if the user syncs from a different session (typically machine) and the first machine hadn’t yet done its sync. Any individual sync without apparent conflict is allowed. But updating an already deleted row will obviously be an issue.

The examples get more complicated - and have to be thought through carefully for a given application. These tools are making it too easy for people to walk in to synchronization issues in application implementation.