syncAccounts

syncAccounts

syncAccounts should come with sane defaults (like in offlineimap) while allowing fine grained tuning. For example, mbsync supports

• Sync {None|[Pull] [Push] [New] [ReNew] [Delete] [Flags]|All} Select the synchronization operation(s) to perform:

  • Pull - propagate changes from Master to Slave.
  • Push - propagate changes from Slave to Master.
  • New - propagate newly appeared messages.
  • ReNew - previously refused messages are re-evaluated for propagation. Useful after flagging affected messages in the source Store or enlarging MaxSize in the destination Store.
  • Delete - propagate message deletions. This applies only to messages that are actually gone, i.e., were expunged. The affected messages in the remote Store are marked as deleted only, i.e., they won’t be really deleted until that Store is expunged.
  • Flags - propagate flag changes. Note that Deleted/Trashed is a flag as well; this is particularly interesting if you use mutt with the maildir_trash option.
  • All (--full on the command line) - all of the above. This is the global default.
  • None (--noop on the command line) - don’t propagate anything. Useful if you want to expunge only.

  Pull and Push are direction flags, while New, ReNew, Delete and Flags are type flags. The two flag classes make up a two-dimensional matrix (a table). Its cells are the individual actions to perform. There are two styles of asserting the cells:

  • In the first style, the flags select entire rows/colums in the matrix. Only the cells which are selected both horizontally and vertically are asserted. Specifying no flags from a class is like specifying all flags from this class. For example, "Sync Pull New Flags" will propagate new messages and flag changes from the Master to the Slave, "Sync New Delete" will propagate message arrivals and deletions both ways, and "Sync Push" will propagate all changes from the Slave to the Master.
  • In the second style, direction flags are concatenated with type flags; every compound flag immediately asserts a cell in the matrix. In addition to at least one compound flag, the individual flags can be used as well, but as opposed to the first style, they immediately assert all cells in their respective row/column. For example, "Sync PullNew PullDelete Push" will propagate message arrivals and deletions from the Master to the Slave and any changes from the Slave to the Master. Note that it is not allowed to assert a cell in two ways, e.g. "Sync PullNew Pull" and "Sync PullNew Delete Push" induce error messages.

• Create {None|Master|Slave|Both}

  Automatically create missing mailboxes [on the Master/Slave]. Otherwise print an error message and skip that mailbox pair if a mailbox and the corresponding sync state does not exist. (Global default: None)

• Remove {None|Master|Slave|Both}

  Propagate mailbox deletions [to the Master/Slave]. Otherwise print an error message and skip that mailbox pair if a mailbox does not exist but the corresponding sync state does. For MailDir mailboxes it is sufficient to delete the cur/ subdirectory to mark them as deleted. This ensures compatibility with SyncState *. Note that for safety, non-empty mailboxes are never deleted. (Global default: None)

This is great but imapfw should go further in this area. For example, users might want to propagate only read flag one way and deletions to the other direction.

Also, users might like to use more than one policy (like running fast syncs most of the times and run full syncs from time to time).

• [ ] Quick sync.
• Enable fine-grained tuning for syncing.
• Diff of the repositories.