>Now to the issue: How do you want to support the change to the structure and >falling back to older versions of the mail server. My implementation reads First of all, I love your idea and we should definitely do it. If I'm reading your description correctly, it could potentially mean we can add all sorts of arbitrary flags in the future, which would be really useful. To handle moving to the new version of the table structure, take a look at serv_upgrade.c to see an entire history of how we've done such things in the past. When the server starts up, it compares its version number to the config variable `MM_hosted_upgrade_level` which tells us the version number of the server that was running the previous time the database was opened. Then we go through a bunch of routines which basically go "if the version number is older than `x` then we need to do so-and-so upgrade..." and then when all of those conversions have been run, it sets `MM_hosted_upgrade_level` to the current running version of the server. At startup, if the version of the database is *newer* than the version currently running, the server immediately exits and tells the operator to upgrade it. We do not, under any circumstances, support moving backwards, so you don't have to worry about that. We'll need to patch serv_migrate.c to handle the new table format, but I'm actually thinking about abandoning that module because it doesn't really work too well on extra-large data sets. I'm quietly developing `ctdl3264.c` which is an *offline* conversion utility that I started hacking together to convert my own database from 32-bit to 64-bit, but I'm starting to realize that it could actually be a pretty good dump-and-load tool with a little extra effort.
Thanks for the great idea and the willingness to implement it. Looking forward to seeing what you come up with!
