> Kolab Systems is thinking of such SQL databases for integration > purposes, where the performance penalty now lies within having to use the > IMAP protocol to gain access to the underlying metadata (seen status, > message indexes) in distributed groupware environments where Cyrus > itself is not the only component that needs access to such information > (but would still remain authoritative, of course, and would be the only > component with write access to most tables). > > While not necessarily the best approach, it seems worth exploring. Yes, this is one of the big reasons why we use RDB backends in many of our products. The downside is performance, of course. But the upside is very big when you need it -- ability to keep one instance of important metadata and allow multiple pieces of software on multiple servers to access it. Most of the time, this metadata is read-often-update-rarely, so we don't need huge write performance. But if we have to synchronise the data across multiple servers and use local files like SQLite/BerkeleyDB/gdbm, we land up building entire synchronisation layers just to ship updates around from server to server. This is not Cyrus-specific -- any metadata which needs sharing across multiple servers seems to be easier to build with a network-accessible database, and an RDB is the commonest of them (SQLite being an exception). Basically, memcached is "better than" BerkeleyDB hashmaps in these situations. Shuvam ---- Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
