The HotSync Id Manager (hereafter HsIdMgr) is responsible for allocating locally and globally unique ids for the content objects stored in HotSync DataStores. Locally unique ids (Luids) are 32 bit integers unique within the device. Globally unique ids are typically 128 bit integers.
The HsIdMgr can associate one globally unique id with several locally unique ids. This association represents a conflict; that is, each local id identifies a datum that is a version of the content for a single object identified by a global id. Conflicts occur when incompatible edits are made to the same logical object in multiple locations. For example, if a contact record is edited on both the handheld and the desktop, and those edits do not result in identical content, then a conflict occurs when the handheld and desktop next sync. HotSync would then note this conflict by allocating a new local id for the object's guid, and identifying the desktop's version of the object's content with that local id.
The modeling of conflicts introduces "aliases", in the form of multiple LUIDs for conflicted versions of a single logical object. When the conflict is resolved, all but one of these versions is deleted. Because this may cause dangling references, the HsIdMgr tracks a referenceable LUID for each logical object. The referenceable LUID is always the first LUID assigned to an object. This allows an object that is created locally to be referenced before it's synced. HotSync guarantees that the referenceable LUID continues to refer to a valid version of the object until it's purged. For example, suppose that non-identical edits are made to a contact on the desktop and handheld, resulting in a conflict at the next sync. Then suppose that the desktop is used to resolve the conflict in favor of the desktop version. Then, at the next sync, instead of simply deleting the handheld version, HotSync will replace the content of the handheld version with the content from the desktop version and delete the desktop version, thus retaining the handheld's referenceable LUID.
The HsIdMgr provides two APIs for retrieving the referenceable LUID for an object, alp_hsim_get_referenceable_luid_for_guid() and alp_hsim_get_referenceable_luid_for_luid(). The latter can be used to retrieve the referential LUID for an object given the LUID for one of its content versions. An application that wants to reference an object may call one of these APIs to get the referenceable LUID. Applications that provide an API for data access should ensure that references are not made to non-referenceable versions of its objects.
The HsIdMgr provides an API for enumerating all conflicted GUIDs in a DataStore, alp_hsim_get_conflicted_guids(). Applications that want to present a UI for tracking and resolving conflicts may use this routine to identify conflicted objects.
In certain cases, deletion of an object will "forward" references to another referenceable LUID instead of nullifying those references. For example, support there are two categories named "Business" and "Business2". When a user renames "Business2" to "Business", it violates the uniqueness constraint for category names. The application may choose to interpret the user's intention as a "merge" of "Business2" into "Business"; in this case, the members of "Business2" become members of "Business". The HSChangeTracker models this as a delete of "Business2" that leaves a forwarding address to "Business". The HsIdMgr supports this use by returning the forwarding address when alp_hsim_get_referenceable_luid_for_luid() is called with a dangling reference to an object that has a forwarding address.
The IdMgr uses "extended" GUIDs to model syncable associations between objects. This allows the identity of the association to be globally unique. An example is the association of a content object, like a contact, with a category object, indicating the object's membership in the category. This "membership" association is identified by a 256 bit extended GUID that consists of the GUID for the content object followed by the GUID for the category.
In general, we define extended GUIDs as follows:
EGUID ::= GUID EGUID ::= GUID, EGUID
The "depth" of an extended GUID is defined as the number of extended GUIDs that it contains. Each extended GUID with positive depth N is composed of a GUID and a nested extended GUID with depth N-1. The extended GUID within an extended GUID is known as the GUID's "extension" or "tail".
Modules | |
| Data Types | |
| API's | |
Generated on Wed Jul 30 07:06:41 2008 by Doxygen 1.4.6 for ALP SDK + Hiker Documentation
Copyright © 1999-2008 ACCESS CO., LTD. All rights reserved.