On 10 Jul, 2006, at 13:43, Andi Vajda wrote:
...
In IMAP, a mailbox uid (a.k.a. "UIDVALIDITY value") has to be a
non-zero 32-bit unsigned value. It's also supposed to be unique
for the mailbox at that path (i.e. deleting & recreating the
mailbox should give a new UID). So, a UUID (128 bits IIRC) won't
work here: Most implementations use a timestamp (an increasing
sequence of integers is also possible).
Understood. I guess the word UID confused me.
However, as you point out, an initialValue isn't really required,
either, and doesn't have the right behaviour w.r.t. deletion and
recreation. Also, a random int could theoretically collide. Maybe
the best thing is to override __init__ to make validityUID a
computed value (like a timestamp).
In that case, a random number can work or, the hash value of a UUID.
hash(UUID()) is a 32 bit number.
It's probably a largely theoretical issue, since people don't
typically delete & recreate mailboxes at a given path very
frequently, but won't hash(UUID()) repeat values at some point?
IMAP's uniqueness requirement (for clients to be able to sync a given
mailbox without re-downloading the entire message list every time) is
that the triple of (mailbox path, mailbox UID validity, message UID)
uniquely identifies a given mailbox.
A similar comment applies to your comments about UUIDs for uidNext
& UIDs: these also have to be 32-bit positive unsigned ints, and
have the additionial requirement of increasing monotonically as
messages are added to the mailbox.
There, hash(UUID()) wouldn't work. The hash value cannot be
predicted with regards to its order and can be negative. Oh well.
Back to timestamps... with all the bugs that this may imply.
Some servers do this, but most just keep incrementing an integer to
generate UIDs for messages in a mailbox.
--Grant
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
