Just a thought, but couldn't you write the imapd process to act more like a web application server in the RDBMS scenario. You can cache data and limit the number of select statements executed on the actual data store. Although one wouldn't have something like cookies for sessions, the username and other characteristics of the message could be used to create a hash identifying the data in the imap server. Imap clients also tend to retrieve the headers only and then retrieve message bodies if someone "reads" the message. For most clients, caching the headers might be a good idea. Of course the timeout value couldn't be to large or they wouldn't get the newest messages in a reasonable time.

You could also seperate the cache from the imap daemon similar to how livejournal.com uses a seperate caching service to limit the overhead on the mysql servers for large mail deployments. Its similar in the sense people want the most recent journal entries just like they want their new messages.

The other advantage to a mail server implemented as a database is that one could add groupwise type functionality as pluggable modules that tied in with the data store. Its overkill, but could be rather neat.

Lucas Holt
FoolishGames.com  (Jewel Fan Site)
JustJournal.com (Free blogging)

[EMAIL PROTECTED] mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to