Changing databases at runtime

[Jonathan Marsden]

On 25 Nov 2002, Rob Siemborski writes:

> On 25 Nov 2002, Erik Enge wrote:

>> I wouldn't rate it as easy unless it was a config option at
>> run-time, not an option to configure at compile-time.

> This wouldn't be tremendously hard to do (probably just a matter of
> replacing some macros with some code that is a bit more clever), but
> there'd be a (small) performance penalty and there isn't really any
> intrest in doing it, since converting databases shouldn't be a
> common operation anyway.

This is in part a packaging and upgrading issue, though.  Especially
when the recomended default choices for what databases within Cyrus
are in what form seem to change over time, and that this may get
'worse' as new backends are implemented, the ability to build a
compiled version of Cyrus that could find and use whatever database
format it can see (or failing that, whatever database some separate
utility can see and then edit into the config files), would probably
help reduce the "I upgraded Cyrus to the latest package, and
everything broke" type of posts -- which in some cases have reportedly
led to users giving up on Cyrus altogether.

I don't know for sure whether a simple and reliable package upgrade is
worth "a (small) performance penalty" for the average user of a
pre-packaged (RPM or .deb) Cyrus, but I suspect it might well be.  And
over time, such sites may become the majority of Cyrus installations.

This probably isn't something of great utility to CMU, but for the
average Linux sysadmin who just wants to grab an RPM or a .deb and
install it and have Cyrus "just work", upgrading as new RPMs/.debs are
released, it could be a big deal in the long run.

Jonathan
--
Jonathan Marsden       	| Internet: jonathan at xc.org	| Making electronic 
1252 Judson Street  	| Phone: +1 (909) 795-3877	| communications work 
Redlands, CA 92374     	| Fax:   +1 (909) 795-0327	| reliably for Christian 
USA            		| http://www.xc.org/jonathan	| missions worldwide