...and a question (SHA1 UUIDs)
murch at andrew.cmu.edu
Thu Sep 6 09:53:27 EDT 2007
Bron Gondwana wrote:
> On Wed, Sep 05, 2007 at 05:02:00PM -0400, Ken Murchison wrote:
>> David Carter wrote:
>>> All from:
>>> 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?
>> - 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).
Project Cyrus Developer/Maintainer
Carnegie Mellon University
More information about the Cyrus-devel