...and a question (SHA1 UUIDs)

[Ken Murchison]

Bron Gondwana wrote:
> On Wed, Sep 05, 2007 at 05:02:00PM -0400, Ken Murchison wrote:
>> David Carter wrote:
>>> All from:
>>>   http://www-uxsup.csx.cam.ac.uk/~dpc22/cyrus/patches/2.3.8/
>>> sha1_uuid_replace.patch
>>> -----------------------
>>> Throw away the existing UUID apparatus (in particular the environment
>>> value CYRUS_UUID_PREFIX used to pass state from master to imapd and
>>> lmtpd). Replace it with simple 20 byte UUIDs which are the message SHA1.
>>> Any existing UUIDs are reset to NIL. I suppose that it would be possible
>>> to pad the existing 12 byte UUIDs to 20 bytes: the chance of a collision
>>> is remote.
>>
>> I'm beginning to sift through this patch in an effort to implement what we 
>> had discussed privately.  Some initial questions:
>>
>> - Do we still need the "uuid_mode" option in imap.conf?
> 
> No.
> 
>> - Can I assume that any mention of "provide_uuid" in the documentation can 
>> be removed?
> 
> Yes, I believe so.  All the UUID infrastructure between master and child
> processes can be ripped out.
> 
> I guess there's still some value in having a "turn UUIDs off" config
> option to allow people who don't want the CPU overhead of calculating
> sha1 values to avoid it.  Unless we're planning to simplify the
> replication system as well by absolutely demanding that UUIDs are
> calculated on all messages.  I can see arguments for both sides, so
> I guess it's down to an executive decision!

Right.  It comes down to whether we want/need to allow replication 
without UUIDs.  We can trigger whether we calculate the SHA1 UUIDs on 
the master by checking to see if 'sync_host' is set.

If we go with a 'uuid_mode' option, my inclination is default it to 
'none' or 'off', so standalone servers aren't wasting CPU by doing SHA1 
(or else we couple check for 'sync_host' && 'uuid_mode' before doing SHA1).

-- 
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University