> I'm thinking in terms of searches primarily, where a query might be: > > select distinct(message_id) from fastheaders > where header = 'to' and contents like '%bob%' > > You're looking for displaying the message, where the webmail application > probably doesn't want to read in the header blocks of the message and parse > them just to show the Date, From, Subject, To, CC, Bcc, Fcc, Reply-To fields.
Yep, that's exactly what we want (searches and fast lookups of common headers). :) But there are more uses too, I think. <interesting comments on imap usage snipped> > My instinct is that this would still be reasonably fast, completely flexible > and generic. Even if the query took slightly longer, the much smaller result > set size and the negligible parsing needed would offset the query speed. In addition to being very flexible/generic for header, this could even be a place for general per-message metadata, not just headers. Any time you have to parse a message, you could store the result if it's cost-effective and will be used again (there was one very specific and useful example in dbmail that I'd mentioned on the mailing list, but can't find it now). But you could also have local uses. Eg. in weDBmail, when you download a message from a pop3 server, I'd like to save an id for which pop3 account it came from so if you forward or reply to it you don't have to parse the headers to try to guess what the sender profile should be (and if you were Bcc:'d you won't ever know). Of course we can just have our own table to track that, but if dbmail had a per-message info table like that, we'd try to use it. -- Jesse Norell [EMAIL PROTECTED] is not my email address; change "administrator" to my first name. --
