On Thu, Sep 02, 2004 at 10:13:11AM -0600, Jesse Norell wrote: > > > Example showing message ids that do not collide on two > > machines using a machine id 001 or 002 received at the > > same time. > > > > - machine 001 msg - received at 2004/09/02 2:10:45:27 > > - unique_id = 2004090202104527001 > > > > - machine 002 msg - received at 2004/09/02 2:10:45:27 > > - unique_id = 2004090202104527002 > > > > > > > > In this scenario either machine could go down before the > > message was replicated to the other. When it came back up > > and the synced again it could commit it without problems. > > I'm not at all familiar with IMAP, would that cause any > problems with imap clients, having "old" unique-id's popping > up at "unexpected" times? Ie. an imap client reads from one > of the disconnected servers and there are a certain number of > messages in the box; the db servers then sync and the client > checks again, finding more messages in the mailbox and these > "new" messages have what appears to be out of sequence > unique-id's. Sounds like it'd probably be rfc-conformant, > but in practice, will it break client behavior? (I don't know > what imap clients would normally do with the unique-id, if they > save it offline, etc...)
It sounds like it would be non-rfc compliant since the unique ids would not always be increasing. If I get a list of messages while one server if disconnected and the max unique id is 1000 and later when the disconnected server is reconnected, there are new messages with unique ids below 1000, this would likely confuse IMAP clients that maintain state on the client side. I'm thinking of offlineimap[1] in particular, but other IMAP clients that support an offline mode would probably have problems too. 1. http://gopher.quux.org:70/devel/offlineimap xn
