sync 01

The 3-way merge approach

As for offlineimap, it's possible to add a new entry-point to the engine.

  {worker}                        {worker}                         {worker}
+----------+                    +----------+                     +----------+
|          |      (drives)      |          |      (drives)       |          |
|  driver  |<-------------------|  engine  +-------------------->|  driver  |
|          |                    |          |                     |          |
+----------+                    +----------+                     +----------+
                                     |
                                     |
  {worker}                           |
+----------+                         |
|          |      (drives)           |
|  state   |<------------------------+
|          |
+----------+

Use case

• In the engine:

right.search(searchConditions) # Async
left.search(searchConditions) # Async
stateMessages = state.search_sync(searchConditions) # Sync

rightMessages = right.getSearchResult_sync() # Sync
leftMessages = left.getSearchResult_sync() # Sync

# The 3-way merge.

# Sample: apply changes on the left side.
# That's the sad part. We must ensure each write is sucessful to update the
# state. We have to process each write sequentially (in a loop) for all the
# updated messages.
success = left.update_sync(message) # Sync mode and slow.
if success is True:
  stateSuccess = state.update_sync(message) # Sync mode and additional time overhead.
  if stateSuccess is not True:
    # Bad. The state backend is not properly aligned with the real data.
    # Taking actions here means new synchronized calls.
else:
  # Raise error or warn.

Pros

• Engine is supposed to be the right place for a 3-way merge algo. All the code about the merge stands where it is expected.
• Simple implementation.

Cons

• All the successful writes of the drivers must be forwarded to the engine. This means the engine must track the results of all the write operations. This defeats the benefits of the async environment and is likely not performance friendly.
• Leads to possible incoherent syncs when updates on the state fail. This is a known issue in offlineimap which is not well-solved and next sync might create duplicates.