Sync Framework Glossary
This glossary lists and defines Sync Framework concepts and terminology.
Terminology
- batching
The process of sending changes in small groups instead of in a one-shot transfer of the data in its entirety.
- change unit
The minimal unit of change tracking in a store. Change units are contained in an item, such as name and address fields in a contact item. In change propagation, only the change units that are changed must be sent. In conflict detection, only changes to the same change unit are considered a conflict.
- client
A service, application, or device that wants to integrate into the Sync Framework architecture.
- clock vector
A replica key/tick count pair that represents updates to a replica. Any change that occurs between 0 and the tick count is contained in the vector.
- concurrency conflict
Conflicts that occur when the same item or change unit is changed on two different replicas that are later synchronized.
- conflict resolution method
The method that is used to determine which change is written to the store if there is a conflict. Typical conflict resolution methods are as follows: last writer wins, source wins, destination wins, custom, or deferred. For custom resolution, the resolving application reads the conflict from the conflict log and selects a resolution. For deferred resolution, the conflict is logged together with the conflicting change data and the made-with knowledge of the change.
- consistency unit
The minimal unit of consistency. Because all changes that have the same consistency unit are sent together, synchronization can never be interrupted when only part of a consistency unit is applied.
- constraint conflict
Conflicts that violate constraints that are put on items or change units, such as the relationship of folders or the location of identically-named data within a file system.
- endpoint
See participant. Synonyms used in the documentation include node and endpoint.
- filter forgotten knowledge
Defines a starting point for filter tracking. A filter-tracking replica can save storage space by removing ghosts and advancing the filter forgotten knowledge to contain the highest version of the ghosts that have been removed.
- filter key
A 4-byte value that maps to a filter in a filter key map.
- filtered replica
A replica that stores item data only for items that are in a filter, such as a media storage replica that stores only songs that are rated as three stars or better. As the rating on a song changes, an item may move in or out of the filter. A developer can define a custom filter that is used to control the item data stored on a filtered replica.
- filter-tracking replica
A replica that can identify which items are in a filter and which have moved in or out of the filter recently. A filter-tracking replica may store item data for items that are not in the filter. A filter-tracking replica can more efficiently synchronize to a filtered replica than a replica that does not track the filter.
- flexible identifier
An identifier that is assigned to various synchronization entities, such as replicas. The identifier can be of fixed or variable length.
- ghost
Ghosts are items or change units in a filtered replica that were in the filter and have moved out. The filtered replica stores metadata for ghosts, but does not store item or change unit data.
- global identifier
A unique identifier that is assigned to a data item. The identifier must be unique across all clients. A global identifier is a flexible identifier and so can be any format. However, the format is typically a GUID and an 8-byte prefix.
- item
A unit of data or metadata that is being synchronized. A typical item of data might be a file or record, whereas a typical item of metadata might be a knowledge item.
- knowledge
The metadata that is maintained by each participant that describes all the changes it has seen. In its simplest form, known as a watermark, a knowledge item is a clock vector that consists of pairs of replica keys and replica tick counts.
- learned knowledge
The current knowledge of a source replica about a specific set of changes, and the logged conflicts of that replica. Learned knowledge answers the question: What will I learn when I apply this batch of changes?
- made-with knowledge
The current knowledge of a source replica, to be used in conflict detection. Made-with knowledge answers the question: What did you know when you made these changes?
- merge tombstone
A marker created when a constraint conflict is resolved by merging the two items in conflict. When a constraint conflict is resolved by merging, the smaller of the item IDs is chosen as the winning item ID and the larger is the losing item ID. The winning item ID is used to identify the merged item. The merge tombstone tracks that the losing item ID identifies the same item as the winning item ID in the synchronization community.
- node
See participant. Synonyms used in the documentation include node and endpoint.
- participant
A provider and its associated replica.
- prerequisite knowledge
The minimum knowledge that a destination provider is required to have to process a change or change batch.
- range
A set of continuous item identifiers to which the same clock vector applies. A range is represented by a starting point, an ending point, and a clock vector that applies to all IDs that are in between.
- replica
A particular repository of information to be synchronized, such as a file system or a database, and the metadata store that represents that repository.
- replica ID
A value that uniquely identifies a replica.
- replica key
A 4-byte value that maps to a replica ID in a replica key map.
- scope
The set of data that is being synchronized.
- synchronization application
A software component, such as a personal information manager or music database, that hosts a synchronization session and invokes synchronization providers to synchronize different data stores.
- synchronization community
A set of replicas that keep their data synchronized with one another.
- synchronization provider
A software component that represents a replica for synchronization. When acting as a source, it enumerates changes from its replica. When acting as a destination, it applies changes to its replica. For data format mismatch, it performs any necessary schema transformation.
- synchronization session
A unidirectional synchronization in which the source provider enumerates its changes and sends them to the destination provider, which applies them to its store.
- tick count
A monotonically increasing number that is specific to a replica and combined with a replica key to make a version.
- tombstone
A marker that is used to represent an item that has been deleted. A tombstone is used to track deleted items and prevent their reintroduction into the synchronization community.
- topology
The set of participants involved in synchronization and the way in which they are connected to each other. For example, in a hub-and-spoke topology, there is a central participant (usually a server) through which all changes flow, and a number of other participants that act as clients.
- version
Metadata that identifies a revision to an item. It consists of the replica key and the replica tick count for the item.