[Dovecot] Replication protocol design

[Timo Sirainen]

On Fri, 2008-05-02 at 07:30 +0100, Ed W wrote:
> Timo Sirainen wrote:
> > Using IMAP protocol for replication has at least two disadvantages:
> >   
> 
> It occurs to me that there is at least one advantage of putting as much 
> as possible into the imap protocol:
> 
> mailclients are kind of a special of replication client.  Really they 
> want to be able to do as much as possible of this stuff as possible 
> also...  Although clients typically lag a few weeks behind new RFCs 
> being written (grin), I guess the point is that if some of this stuff is 
> available via IMAP or an IMAP extension then others might one day use or 
> benefit from it?

I agree that it would be nice to offer this capability for IMAP clients,
but I don't see a way to do this in any reasonable way. If the client
wants a continuous replication for all mailboxes the resulting protocol
will barely even look like IMAP anymore. And trying to merge all the
initial sync + continuous replication + IMAP functionality to the same
process would be quite ugly.

There is still a small hope though. Merging initial sync + IMAP
functionality could be possible somewhat cleanly since the initial sync
is quite close to QRESYNC functionality. But I'm not yet convinced that
it's a good idea to separate initial sync and continuous replication to
separate processes. I'll think more about this once I start planning
replication milestone 2 details.

> Does a modification to IDLE to monitor more folders help us at all?

Not really. IDLE in general doesn't allow anything else than getting
EXPUNGE notifications immediately. Anything else is allowed to be sent
immediately to the client even if it doesn't use IDLE (old Dovecot
versions used to do this, but it caused problems with some clients).

Anyway even if Dovecot finds out that there were changes in other
mailboxes, it would have to notify about these to the client somehow. It
basically means either a) adding a mailbox parameter to all untagged
replies (ugly) or b) sending a "mailbox xyz changed" notification and
have the client change the mailbox to find out what changed
(inefficient).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://dovecot.org/pipermail/dovecot/attachments/20080503/8d6c6e2d/attachment.bin