Why Don't You Build A Store Driver For MySQL, Postgres, Oracle, etc.?

You're probably asking this, because…

• You want to access your emails
• You want to backup your data
• You're interested how Citadel stores its data

Although there are solutions in the market that use SQL database backends, Citadel doesn't. You wouldn't want to access the database on an SQL basis on dbmail either, since it would harm the application's abstraction model. However, Citadel does offer several ways to access your email without hurting that principle. The preferred way is to use the Citadel Protocol to access your email. If you want to get a more detailed picture, have a look at our sample php client. The other ways would be using IMAP to access them, or make Citadel send them to another facility.

There are several ways to do so. Both of them require a service window. For an architecture-independent backup (if you were to move from a SPARC box to an Intel one, for example) Citadel has ARTV Export & Import. The quicker way may be copying the bdb files with the data/ directory, which you may speed up by using LVM and Snapshots

Citadel uses Berkeley DB because it is powerful, reliable, and offers the best matching access and tightest integration to Citadel's data model.

Berkeley DB is not an RDBMS. All it does is key/value pairs. It does that very well, in fact. Citadel has no schema layer in its storage abstraction. Therefore if one were to write a MySQL store driver, all of the tables would look like this:

CREATE TABLE cdb00 (
  key LONGBLOB INDEX,
  data LONGBLOB
);

If you actually wanted the store to be manageable in MySQL, you'd have to convert the entire Citadel server to use a schema layer, and then you'd have to build a schema layer driver for compatibility with Berkeley DB … and it would have to be backwards compatible with the current store.

It is primarily due to these reasons that it isn't very likely that a MySQL store driver will be built and why the Citadel Project is highly committed to continuing to use Berkeley DB for the foreseeable future.

Any other store drivers would need to be contributed by someone in the community. And although we currently have no plans to write additional store drivers ourselves, we have kept the API clean enough that it is possible to do so.