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.
I had planned to have a separate mapping file, something like taginfo.dat, that users could transfer between profiles. Scott suggests using preferences to store the tag info. That would save me some implementation time, but make it more difficult for users to share taginfo across profiles and machines. I plan on hiding this behind an nsIMsgTagInfo service so we can choose a persistence mechanism later, and if people want to plug in other mechanisms, they can.
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.
