sync 05

State for remotes

With this design, a state controller is attached to remote repositories only.

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

Use case

• In the engine:

# Notice the searchUpdated method would likely be the search method with fixed
# conditions.
left.searchUpdated(searchConditions, right.getName()) # Async
right.searchUpdated(searchConditions, left.getName()) # Async

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

# No merge at all.

left.update(rightMessages)
right.update(leftMessages)

• In a state controller, at discover step:

stateMessages = self.state.search(searchConditions) # Sync: might worth putting
                                                    # the backend out in a worker.
messages = self.driver.search(searchConditions) # Sync

# 2-way merge.

return mergedMessages # To the engine.

• In a state controller, at update step:

# Writes must update the state, too.

• In the drivers:

# Writes support both creation and updates.

Pros

• Only remote repositories are attached a state. The state is given the other side name (or whatever uniq) so that the data can be properly namespaced.
• No need for a merge algo. Only updated messages are returned by the drivers.
• Engine gets damn simple!

Cons

• The writes of the drivers must support both creation and update. Not sure this is a real con: this might be required whatever the design...
• The engine needs a way to update the chain of controllers.