Paul J Stevens <[EMAIL PROTECTED]> said: > I could some threaded model. I've been thinking about header caching: We > implement a cache table with fields for every header you wish to cache. > If a sysadmin adds a column for some funky X-Field he wants to cache, the > insertion code immediatly starts using the extra header field, while the > retrieval code degrades gracefully if a message is not yet in the cache. > It would be nice to be able to launch a slow priority thread that > gradually starts to analyze all older messages without interfering with > the imap interaction.
It would be interesting to have a "side process" running that had various threads for on-the-fly maintenance and update tasks... but I'd rather stick to using threading as a more efficient way of handling connections socket and database (especially for Oracle, where one process with ten threads handling ten users needs only one OCI connection and saves considerable database overhead). We could figure out that "side process" might look like, but I don't think it could be part of any of the server processes without hugely rethinking how, for example, IMAPD and POP3D let each other's "cleanup threads" know what they're doing. And, before anyone suggests it, "pop3 never needs header caching, so only imapd would have the add-a-header thread" I *really* don't like that idea -- as much as possible, we should keep the daemons similar, on a common codebase, and only differing in their protocol handling and communications routines. By refactoring the IMAP code to eliminate globals and use single-output routines that take a high level list structure and produce correct protocol formatted parenthesis and whatnot, we're almost done with threading the application. Just slap threading into the process manager, double check for stupidity and corner cases (80% of the effort anyways) and that's it. Right!? Aaron --
