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=None) # Async
left.search(searchConditions=None) # Async
stateSearchResults = state.search_sync(searchConditions=None) # Sync

rightSearchResults = right.getSearchResult_sync() # Sync
leftSearchResults = 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.
success = left.update_sync(message) # Sync mode and slow.
if success is True:
  stateSucess = state.update_sync(message) # Sync mode and additional time overhead.
  if stateSucess 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 state. This means the engine must track the results of the write operations. Hence, the engine has to wait for each write. 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. Known and issue in offlineimap which is not well-solved. Next sync might create duplicates.