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