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
