589
edits
Changes
→Implementation Issues
I think we're going to have to do something like Pine does of storing what keywords to display as tags, and what tag to display. Under normal circumstances, the user should never have to edit this file. We'll pre-populate it with the custom keywords we use (Junk/NonJunk/$label1-6) and mark them as keywords to ignore. When the user adds a tag, we'll add an entry to the file, along with the tag to display for the keyword. The keyword will be created by stripping out the illegal chars in the tag, and converting to imap mod utf7 (probably in the other order). When the user "renames" a tag, we'll just redo the mapping, and replace the tag in all the messages. When the user deletes a tag, we'll just mark the keyword as one to ignore, and remove the tag from all the messages that have that tag. This mapping file should be cross account, probably, so that if you add a tag, it applies to all accounts.
As far as losing tags when the .msf files are deleted is concerned, my plan is to add UI for rebuilding a summary file, and have the implementation be non-destructive as far as keywords is concerned. It would basically reparse the folder, and rethread the messages, but maintain the keywords. This should make it less likely that people will delete the .msf file directly.
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
