> > While on the subject, I'd like to be able to cache a couple flags per
> > message for whether it's been forwarded, replied to, etc. With a good
> > design for per-message data cache, would it make sense to move all the
> > *_flag flags and maybe unique_id out of the message table down the road?
> > They are basically the same thing, just specific to pop or imap. I don't
> > think you'd get any space savings (in fact, would probably loose a little),
> > but it might be a cleaner layout.
>
> The primary design goal is to preparse messages at insertion and avoid
realtime parsing as much as possible.
> You seem to be talking about extended imap message attributes through the
PERMANENTFLAGS response. A different
> beast all together (much simpler).
I'm not very familiar with imap, but I think that'd be something different.
I was meaning if there's a generic per-message data cache, it might be cleaner
to move all of seen_flag, answered_flag, deleted_flag, flagged_flag,
recent_flag, draft_flag and maybe unique_id out of the messages table into
that more general table. Those who don't use pop3 could live without storing
a unique_id (I think), and those not using imap could do without all the *_flag
bits. I don't think performance would be much different than now, and there's
no space savings benefit - it's just whether it would make a cleaner layout
that way.
--
Jesse Norell
jesse @ kci.net
