Merger and Format Conversion

This page summaries the design and implementation of OpenSync use of the Merge in combination with Format Conversion.

Background

Format C is a "common format" which needs to support all capabilities which could be used by any format.

This diagram should show all possible combination where the format conversion and merger/demerge can be invovked. The order of this calls is very important - since it could cause dataloss if done in the wrong order. The simplified sync consists of two major conversion. CONV#1 is the the conversion path which is required to prepare for the engine internal comparing of changes. For comparing both changes needs to be available in the same format. In most cases a conversion to a "common format" is required (e.g. Format C). A "common format" must handle all capabilities. CONV#2 is the conversion from the "common format" to the peer format (e.g. Format B or Format A).

This Sync shows following real-life scenario:

• Group with 2 Members
• Member #1 has Format A (regular format with limited capabilities)
• Member #2 has Format B (regular format with limited capabilities)
• Both Member have Capabilities reported
• Both Member have archived/cached data to Merge from previous syncs
• Both Members report the same change as MODIFIED
• Engine detects that changes are SIMILAR but not SAME -> conflict
• Conflict resolution (e.g. configuration, selection by user, ....) decided that change from Member #2 wins
• Write of the winning/master change to Member #1 is required

Problem: Which format is required for merge/demerge?

For CONV#1 and CONV#2 are two possibilities for each conversion:

• conversion before merge (CONV#1A)/demerge (CONV#2A)
• conversion after merge (CONV#1B)/demerge (CONV#2B)

Simple Conversion with Merger/Demerger?

	No Conv. Dataloss
CONV#1A	yes
CONV#1B	yes
CONV#2A	no
CONV#2B	yes

Only conversion CONV#2A would cause dataloss in combination with demerger:

• Possible dataloss from Format C to Format A due to potential missing capabilities of Format A to handle all field/capability
• Only Format C (a "common format") has to guarantee to handle all fields/capabilities

Combined Conversion Path with Merger/Demerger?

Since CONV#2A would cause dataloss only two combinations of CONV#1 and CONV#2 are left:

• CONV#1A & CONV#2B
• CONV#1B & CONV#2B

	No Conv. Dataloss	Reusable Archive/Cache
CONV#1A & CONV#2A	no (dataloss at CONV#2A)	no
CONV#1A & CONV#2B	yes	yes (cached as Format C)
CONV#1B & CONV#2A	no (dataloss at CONV#2A)	yes (cached as Format A)
CONV#1B & CONV#2B	yes	no

Another problem which needs to be taken in account: "Reusable Cache/Archive?":

• The first action handled by the demerge function is to write the an entire copy of the orignal change/entry in the current format into the Archive/Cache?
• The entire change/entry in the Archiv/Cache? gets written per Member (so each member has it's own cache/archive)
• Since for CONV#2 only conversion option CONV#2B is left, the format, which got used to Archive/Cache? write, is always: Format C
• When the merge gets called the reported changed needs also Format C, since the entry in the Archive/Cache? is only available in Format C
  • This requires that CONV#1 is CONV#1A - to convert the original reported format - in advanced - to the same format as in the Archive/Cache?

Final proposal for Merger and Conversion combination