Re: Git for redundant mail servers

[David Woodhouse <dwmw2@infradead.org>]

On Sat, 2005-04-23 at 22:12 -0700, David Lang wrote:
> 1. when a new message arrives it gets given a numeric messageid, this 
> message id is not supposed to change without fairly drastic things 
> happening (the server telling all clients to forget everything they know 
> about the status of the mailbox). this requires syncronization between 
> servers if both are receiving messages.

Yeah, that's the most interesting part. One option would be to require
quorum before a server is allowed to add to a mailbox -- but that would
render the thing unsuitable for _intentional_ offline use, where you
want to be able to move mails from one folder to another on your laptop
while it's disconnected.

Since it should be relatively rare for 'competing' commits to occur
during periods of disconnection, I suspect that the solution doesn't
have to be particularly efficient. I'm not sure I'd really want to
change UIDVALIDITY if it happened, but perhaps we could simply remove
_all_ the affected UIDs, and assign new UIDs to the same mails.

In practice, it's far more important that for us to ensure that an
existing UID _never_ refers to a different mail, than it is to make sure
that a given mail always keeps the same UID.

> 2. git effectivly stores snapshots of things and you deduce the changes by 
> comparing the snapshots. for things like flags changing this is a 
> relativly inefficiant way to replicate changes (although if one server is 
> offline for a while it could be a firly efficiant way to do the merge)

We don't have to stick _precisely_ to Maildir -- but flag changes are
just a rename in Maildir, leaving the mail object entirely intact while
changing only the tree. That isn't _so_ bad; but yes, it could probably
be done a little better than just "Maildir in git".

-- 
dwmw2