statuscache

Ken Murchison murch at andrew.cmu.edu
Thu Jan 17 19:11:01 EST 2008


Bron Gondwana wrote:
> On Thu, Jan 17, 2008 at 02:47:27PM -0500, Ken Murchison wrote:
>> Looking (again) at integrating this.  Two observations, the first somewhat 
>> minor, and the second somewhat major:
>>
>> - statuscache v.2 doesn't have support for HIGHESTMODSEQ.  This is trivial 
>> to add to a v.3.
> 
> Yeah, shouldn't be a big problem.
> 
>> - statuscache v.2 stores statuscache_data as a binary blob, which is 
>> platform dependent (byte-order & word size).  This make statuscache.db 
>> non-portable.  I believe that this might be the first cyrusdb that would be 
>> non-portable.  Does anybody care?
> 
> Hmm - it would be a very minor cost to make it platform independent.  On
> the flip side, it's not supposed to persist over shutdowns of Cyrus
> anyway.
> 
> Still, I would vote for fixing that too - might as well keep the
> platform safeness.  Processor time is cheap compared to disk IO
> at least in our setup.

The only tricky part is going to be upgrading from v.2 to v.3.  If its 
not designed to be persistent and/or migrated between platforms, I'm not 
sure I care, since your design is definitely quicker.

I'm in the process of refactoring your patch a little, and I'm going to 
leave the storage method alone for now.  I'll send you my patch when 
complete.  I'll have it done later tonight, after I make dinner for my kids.

BTW, is statuscache:log necessary, or is it just for debugging?

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


More information about the Cyrus-devel mailing list