589
edits
Changes
no edit summary
Iterating over all the db's and messages to rename or remove a tag would be ugly. So we'll use the mapping file for that as well, and just stop displaying those tags. That means we'll store the keywords in the dbs, and do the conversion at display time, even for local folders, etc.
How are we going to store the keywords in the db? One property, or multiple properties? If one property, comma-separated, with ',' escaped? It turns out that we're already storing imap keywords in a single property on the header, space delimited. Unless there's some compelling reason to change that, I think we'll go with that approach. == Tasks == Local mail-specific: 1. When downloading pop3 mail, leave an x-mozilla-keys header with space for writing tags.2. When parsing a mailbox, parse the x-mozilla-keys header(s)3. When setting tags on a local message, write to x-mozilla-keys header if room4. When compacting a folder, if we have more tags in the db for the msg than we have space in the mailbox, add an other x-mozilla-key header5. Make sure x-mozilla-keys are stripped the same way x-account-key is stripped Tag <-> Keyword mapping service 1. Define interface2. Write file/io code3. Implement methods4. Upgrade from labels Design methods for getting and setting tags
