[Chandler-dev] Chandler IMAP server parcel

Andi Vajda vajda at osafoundation.org
Mon Jul 10 13:43:02 PDT 2006

On Mon, 10 Jul 2006, Grant Baillie wrote:

> Thanks for looking at that code: Most of your comments are right on the 
> money. IMAP has restrictions on what UIDs can be, though: see below.
> On 7 Jul, 2006, at 11:00, Andi Vajda wrote:
>> ...
>>    validityUID = schema.One(
>>        schema.Integer,
>>        doc = 'The unique id number of this mailbox.',
>>        initialValue = random.randint(1000000, 9999999),
>>        )  #@# why not use a UUID ?
>>           #@# from chandlerdb.util.c import UUID()
>>           #@# initialValue = UUID()
>>           #@# also, maybe this should be in __init__() so that all 
>> mailboxes
>>           #@# don't endup with the same UID
>>           #@# (an initial value is not required, by the way)
> 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.

> 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.


More information about the chandler-dev mailing list