Abstract: Systems and methods that enable removal of data from an endpoint, while not propagating such removal to other endpoints when synchronizing data sources associated therewith. A designation component can indicate items as forgotten items, wherein such items are being known to an endpoint and deleted therefrom—yet, reintroduced therein and reappearing (e.g., as a create) upon re-synchronizing with the replica over again. Moreover, the forgotten items can employ additional metadata such as in from of an additional bit that indicates whether an item is a forgotten item.

Abstract: Systems and methods that enable removal of data from an endpoint, while not propagating such removal to other endpoints when synchronizing data sources associated therewith. A designation component can indicate items as forgotten items, wherein such items are being known to an endpoint and deleted therefrom—yet, reintroduced therein and reappearing (e.g., as a create) upon re-synchronizing with the replica over again. Moreover, the forgotten items can employ additional metadata such as in from of an additional bit that indicates whether an item is a forgotten item.

Abstract: Systems and methods that enable removal of data from an endpoint, while not propagating such removal to other endpoints when synchronizing data sources associated therewith. A designation component can indicate items as forgotten items, wherein such items are being known to an endpoint and deleted therefrom—yet, reintroduced therein and reappearing (e.g., as a create) upon re-synchronizing with the replica over again. Moreover, the forgotten items can employ additional metadata such as in from of an additional bit that indicates whether an item is a forgotten item.

Abstract: Systems and methods that enable removal of data from an endpoint, while not propagating such removal to other endpoints when synchronizing data sources associated therewith. A designation component can indicate items as forgotten items, wherein such items are being known to an endpoint and deleted therefrom—yet, reintroduced therein and reappearing (e.g., as a create) upon re-synchronizing with the replica over again. Moreover, the forgotten items can employ additional metadata such as in from of an additional bit that indicates whether an item is a forgotten item.

Abstract: Conflicts detected during synchronization of replicas are enumerated and resolved according to a specified policy, comprising conditions and actions or simply a specified action. Specified actions may be drawn from a set of standard actions and custom actions may also be composed. The conflicts are enumerated and resolved in logical groups. A logical group is a collection of one or more item envelopes, each comprising entities, such as items, links, and/or extensions. In an example configuration, both constraint-based conflicts, such as a name collision, and non-constraint-based conflicts are handled via the same application programming interface.

Abstract: A description of the hierarchically-structured document is accessed and converted into an early-bound object having at least some of the same properties as the hierarchically-structured document, and having at least some of the methods that may be performed on the hierarchically-structured document. When a function call is placed to the early-bound object, the early-bound object causes the appropriate corresponding changes to be affected on the hierarchically-structured document while maintaining change tracking information for the document. This reduces the difficulty when drafting source code for a program that interfaces with hierarchically-structured documents that can have varying structures and may be governed by complex change tracking rules.

Abstract: Systems and methods that enable removal of data from an endpoint, while not propagating such removal to other endpoints when synchronizing data sources associated therewith. A designation component can indicate items as forgotten items, wherein such items are being known to an endpoint and deleted therefrom—yet, reintroduced therein and reappearing (e.g., as a create) upon re-synchronizing with the replica over again. Moreover, the forgotten items can employ additional metadata such as in from of an additional bit that indicates whether an item is a forgotten item.

Abstract: Systems and methods for synchronizing data stores. A framework including a sync runtime enables consistent and manageable synchronization between a data store and multiple, diverse back end data stores. The sync runtime provides services such as change enumeration, conflict detection, metadata management, item ID matching, sync interruptability, and the like that are accessible to configurable adapters over an application programming interface. Each synchronizing data store can uses a sync controller to initialize an adapter that can access the services provided by the sync runtime. The sync controller can use a profile to configure each adapter. The profile can identify conflict resolution policies, synchronization filters, source and destination folders, sync direction, and the like.

Abstract: A data store in which changes are not tracked is synchronized with a data store in which changes are tracked utilizing a shadow store. The shadow store contains shadow data indicative of the most recent synchronization operation between the data stores. The shadow data comprises hash values of the data items in the limited or non-change-tracked data store. Changes to data items in the limited or non-change-tracked data store are operated on to provide respective hash values. The hash values are compared with the hash values in the shadow data. If the hash values differ, changes are appropriately applied to the data store, and the shadow data is appropriately updated. In an example embodiment, hash values are obtained from one-way hash functions, such MD5, SHA-1, SHA-256, or the like.

Abstract: Mechanisms are provided for identity mapping in synchronization systems. For example, entities can be mapped across various entity stores, such that an entity in one store can be identified with an entity in another store even if such entities are of different types. When entities are being synchronized across various entity stores, new or updated entity identities (and associated metadata) can be supplied to these stores as part of the same operation as that used for supplying changes during synchronization: entities can be merged and associated identity information and metadata can be changed accordingly; entities can be resurrected and new identity information can be created; metadata can be utilized even though entities are deleted, and so on.

Abstract: A protocol for replicating replicas in a sync community. Each replica maintains a knowledge that represents changes that the replica is aware of. Each replica does not typically maintain knowledge about other replicas. The protocol includes messages that include knowledge about changes on the various replicas. Using the knowledge, the replicas can enumerate changes and send the changes using asynchronous messages that do not need to be received in any particular order. The protocol enables filters to ensure that a valid replication is possible using a minimum knowledge argument. The protocol also enables replicas to partially replicate using filtered knowledge.

Abstract: Mechanisms are provided for identity mapping in synchronization systems. For example, entities can be mapped across various entity stores, such that an entity in one store can be identified with an entity in another store even if such entities are of different types. When entities are being synchronized across various entity stores, new or updated entity identities (and associated metadata) can be supplied to these stores as part of the same operation as that used for supplying changes during synchronization: entities can be merged and associated identity information and metadata can be changed accordingly; entities can be resurrected and new identity information can be created; metadata can be utilized even though entities are deleted, and so on.

Abstract: A data store in which changes are not tracked is synchronized with a data store in which changes are tracked utilizing a shadow store. The shadow store contains shadow data indicative of the most recent synchronization operation between the data stores. The shadow data comprises hash values of the data items in the limited or non-change-tracked data store. Changes to data items in the limited or non-change-tracked data store are operated on to provide respective hash values. The hash values are compared with the hash values in the shadow data. If the hash values differ, changes are appropriately applied to the data store, and the shadow data is appropriately updated. In an example embodiment, hash values are obtained from one-way hash functions, such MD5, SHA-1, SHA-256, or the like.

Abstract: Conflicts detected during synchronization of replicas are enumerated and resolved according to a specified policy, comprising conditions and actions or simply a specified action. Specified actions may be drawn from a set of standard actions and custom actions may also be composed. The conflicts are enumerated and resolved in logical groups. A logical group is a collection of one or more item envelopes, each comprising entities, such as items, links, and/or extensions. In an example configuration, both constraint-based conflicts, such as a name collision, and non-constraint-based conflicts are handled via the same application programming interface.

Abstract: Systems, methods, and computer program products for synchronizing items at replicas within a topology is disclosed. Items are stored in physical tables at the replicas. The physical table layouts at each replica can differ but are mapped to a common logical view. When a replica receives an indication that synchronization should be performed, the replica determines if changes have been made at the replica that should be mapped to the logical views. Replicas can facilitate this by comparing local change enumerations for changes made in physical tables to synchronization local change enumerations for changes in the logical views. Any changes that need to be synchronized are sent through the logical views to other replicas in the topology.

Abstract: A description of the hierarchically-structured document is accessed and converted into an early-bound object having at least some of the same properties as the hierarchically-structured document, and having at least some of the methods that may be performed on the hierarchically-structured document. When a function call is placed to the early-bound object, the early-bound object causes the appropriate corresponding changes to be affected on the hierarchically-structured document while maintaining change tracking information for the document. This reduces the difficulty when drafting source code for a program that interfaces with hierarchically-structured documents that can have varying structures and may be governed by complex change tracking rules.