On Wed, 2007-05-16 at 20:27 +0200, Gunter Ohrner wrote:
Yes, I think treating mailboxes similary to keywords is ideal. There Except if you want to handle some mailboxes in a special way it's easier if they're separated on disk. Such as renaming or deleting mailboxes is a lot easier.They're based on filtering rules. I don't
Am Mittwoch, 16. Mai 2007 schrieb Timo Sirainen: think they support "copying" messages. So the virtual folders are easily rebuilt by just re-applying the filters into all the messages.
Not neccessarily if you add one level of indirection, simply numbering the mailboxes by index numbers internally and providing a number/name mapping somewhere. This way, a mailbox can be renamed easily simply by updating the map, and might by deleted by removing the map entry. Stale index number may be left in the messages and might cleaned up the next time a message's folder list is updated or messages are expunged.
Right. This would also make it use less space inside the dbox files. There already exists a mailbox list index in v1.1 which contains mailbox ID <-> name mappings. But I'm still a bit concerned of its stability. There are two things that could be done:
Have another human readable mailbox ID <-> name mapping file which is used if the binary index is corrupted. If mailboxes are created/deleted/renamed often, this would just slow things down. Might be a good idea optionally though.
If the ID <-> name mapping is lost, the mailboxes could be created using those IDs as their names. That would be a lot better than just having all the mails merged into a single mailbox. As additional help, there could be a couple of built-in mailbox IDs for INBOX, Trash and Drafts. Perhaps that could be admin-configurable, but then again adding new IDs could make it conflict with existing ones. Perhaps just a single 1=INBOX would be enough..
The mailbox IDs could have a validity number as well, similar to UIDVALIDITY for message UIDs. That would make sure that it's safe to use the validity+ID combination to uniquely and permanently identify a mailbox, even if the mailbox list mapping was completely rebuilt (in that case it would get a new validity).