Bron Gondwana wrote: > On Mon, Jan 04, 2010 at 09:11:10AM +0100, Simon Matter wrote: >>> Or you can use a dummy backend. It's a backend which always says « OK >>> » when you try to write in it, and always says « not in db » when you >>> read in it. This backend was never committed into cyrus-imapd... Here >>> is an up-to-date version. >>> >>> Then add this in imapd.conf : >>> duplicate_db: dummy >>> >>> Ken, Bron : do you plan to include this backend into cyrus-imapd ? >>> It's very handy when we don't want to use a database (here we often >>> use dummy for annotations). >> It looks really useful to me. Any chance this will go into upstream? I'd >> prefer to include it in my RPMs if I know it's also in upstream. > > It certainly will! There's a bit of 2.3 vs 2.4 uncertainty about where > to put code. I think we've pretty much put 2.3 into maintainence mode. > I'm telling everyone that we're releasing 2.4 in April on the theory that > if you repeat something often enough it becomes true! Do we really need a dummy backend, or should we just rewrite the code so that non-critical DBs can be specified as nil/none/null and just not make the database calls? Also, in the case of disabling annotation_db, we shouldn't be advertising ANNOTATEMORE/METADATA in the IMAP capabilities. In the case of disabling duplicate_db, we shouldn't be allowing the Sieve Vacation extension, and we can't prevent mail loops caused by Sieve Redirect. -- Kenneth Murchison Systems Programmer Project Cyrus Developer/Maintainer Carnegie Mellon University ---- Cyrus Home Page: http://cyrusimap.web.cmu.edu/ Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
