|
Any PDA device, whether it is a Palm, Pocket PC, WinCE, Psion, EPOC or some other variant, manipulates data internally. These devices are battery powered, as is their memory. If the batteries die, the memory is cleared and all the data entered is lost. To remedy this, there must be some way to back up the data. In most circumstances, this will be to a local desktop database held on a PC.
This local data is rarely simply stored. It is invariably accessed by a local application that will allow you to change the data. Therefore, we have a scenario where data is stored in two different physical locations (the PDA and the desktop) and is capable of being changed in either place.
The method, by which we use data from both these places to produce one simple, consolidated database that is then copied to both locations, is known as synchronization.
On the face of it, synchronization merely merges two databases to give a single, consolidated database. In practice, this proves to be fairly complex. For example:
You meet a friend after work and they tell you that they have moved. They give you their new address and you update your PDA with this information, changing the address to read 1243 The High Street. A few days later (without having synchronized your PDA), your friend calls you at the office to tell you that he gave you the address incorrectly. You update the desktop data with the correct address, 1234 The High Street.
What happens when you come to synchronize your data? We know what we'd like to happen, but what actually happens? The following table describes how Palm handles conflict resolution:
 |
 |
 |
 |
 |
Archive the handheld record then delete from handheld and desktop |
 |
|
Delete from handheld and desktop |
 |
|
Update desktop record |
 |
|
Insert handheld record to desktop db |
|
|
Archive the desktop record and delete from handheld and desktop |
|
|
Delete from handheld and desktop |
|
|
Update handheld record |
|
|
Insert record to handheld |
|
|
If both changes are the same, nothing happens. If they are different, a new record is added to the handheld (from the desktop) and a new record is added to the desktop (from the handheld). In other words, an extra record is added. |
|
|
The updated record is copied to the handheld |
|
|
The updated record is copied to the desktop |
|
|
Archive the handheld record and update handheld record from the desktop record |
|
|
Archive the desktop record and update the desktop record from the handheld record |
|
|
Archive the handheld record then delete from desktop and handheld |
|
|
Archive the desktop record then delete from desktop and handheld |
|
|
Add to archived database |
|
|
If both changes are the same, archive both the handheld and desktop records. If not, do not archive the handheld record but add the desktop record to the handheld and add the handheld to the desktop |
|
|
Do not archive the handheld record. Instead, replace that record with the desktop record |
|
|
Archive handheld if changes are the same then delete from both. Otherwise, do not archive the desktop but add the desktop record to the handheld and the handheld record to the desktop |
|
|
Do not archive the desktop but replace the desktop record with the handheld record |
Note that not all circumstances are identified, merely ones that may require resolution. For example, we do not show what would happen if a record were inserted at the PDA and a record were inserted at the desktop, as it is clear to see that the PDA record will be added to the desktop and vice-versa.
This table is complete, in that it discusses archived records as well (an audit feature, if you will). This appears to complicate the issue but, for now, examine the situation where both the handheld and the desktop records are updated, and ignore all references to archive.
To answer our original question, we see that Palm has adopted a scheme whereby data is never lost. In fact, it will duplicate data rather than face the option of possibly deleting data that should not have been deleted. In our case, we now have two records for our friend. One has the correct address and the other has the incorrect address. But which is which? We have to rely on memory and delete the one that we think is wrong. Clearly, this is not the perfect situation.
In the circumstance above, it would have been preferable to have the desktop record overwrite the handheld record. Of course, this may not always be the case. Sometimes, it would be better to have the handheld record overwrite the desktop record. In both cases, it would probably be preferable to have the record that was changed last take precedence.
Currently, the Palm databases have no way of time stamping records to deduce which was added last. On top of that comes the question of time stored on the Palm and time stored on the desktop. If there is a discrepancy between those times, which takes precedence?
It should be becoming clear that a synchronization policy is set in place by establishing rules on what should be done with data under a given circumstance.
By examining the table above, we can also foresee other problems that may arise. For example:
There are a number of incidents where we would store two copies of a record to an archive. This contention should be reduced.
It is wholly possible to have two persons in the address book that share exactly the same details. This being the case, if you update one of those records, how would the HotSync process know which record to update? One, the other, or both?
We may also be able to see room for improvement. For example, synchronization is an 'all or nothing' approach. Might it occasionally be preferable to limit both the rows and columns that are considered for synchronization?
This introduces us to some of the complexities that industrial grade synchronization and replication methods have to solve.
|
