> 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...) Also, in the above scheme, you do have potential for unique-id collisions for messages delivered to the same machine w/in the same ms .. not likely, but still possible. You might want to throw in both a pid and a sequence number per pid, too. -- Jesse Norell [EMAIL PROTECTED] is not my email address; change "administrator" to my first name. --
