Changes

Jump to: navigation, search

Thunderbird2:Tags

1,943 bytes added, 00:41, 10 March 2006
no edit summary
* Search on messages with a tag
* Create saved searches based on tags
 
== Implementation Issues ==
 
These are basically me thinking aloud so please pardon the rambling.
 
How should we store user-defined tags on an imap server? How should we store them in the db?
 
There are a bunch of issues here:
 
IMAP keywords allow basically alphanumeric keywords; no spaces, no special characters. We can use imap mod-utf7 to handle unicode chars, but some special chars can't be represented.
 
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.
 
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
589
edits

Navigation menu