[Chandler-dev] Chandler IMAP server parcel
grant at osafoundation.org
Mon Jul 10 19:05:59 PDT 2006
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.
More information about the chandler-dev