Services/Sync/WEP/104

	THIS PAGE IS A WORKING DRAFT
	The page may be difficult to navigate, and some information on its subject might be incomplete and/or evolving rapidly. If you have any questions or ideas, please add them as a new topic on the discussion page.

WEP 104 - Partial Views

• Champions: Edward Lee <edilee at mozilla dot com>
• Status: Draft
• Type: ?
• Created: 2009 Aug 24
• Reference Implementation: ..
• WEP Index

Introduction and Rationale

Currently Sync Engines can assume that they have all the data from the server before uploading new data, and this allows local changes and incoming server data to be reconciled before upload. Sync Engines need to be rewritten to handle a partial view of data for partial sync.

One aspect of having all the data before upload is being able to handle duplicate data right away and make sure the server has a single name for the data. This is handled now by doing a "first sync" so everything locally is compared to everything from the server. With partial sync, not everything would be downloaded in the first batch.

Another aspect of having the whole dataset is that relations among the data are known by examining the current structure. With partial sync, a relation, e.g., a parent, might not yet be synced, so changes that result in uploading the data will need to upload the correct parent reference to the cloud.

Proposal

Because each client might get duplicate data in different orders, Sync can't just pick the local or server GUID as the winner. One way to ensure each client picks the same GUID without having seen all the data is to have an absolute ordering. This can be done by picking the "smaller" of the two GUIDs -- doing a string comparison character by character until one is ASCII less than the other.

Once the correct GUID is chosen, the "wrong" GUID is removed from the server, so that other clients do not need to also process the "wrong" GUID. For the client that is generating the "wrong" GUID, it will eventually sync the "right" GUID and switch the local item to it.

Because each engine is free to determine what it considers a duplicate, some parts of the data of "duplicate" records might actually differ, so it's up to the engine to merge the results. So Sync needs to correct the GUID of the incoming/local record, provide the incoming record to the engine to update, and upload the newly merged result for other clients.