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
