Actually, storing messages in databases is provably not scalable. Unless that database is perhaps a file system.
RDBMS's typically don't handle data that varies from 50 bytes to several megabytes. They MIGHT do okay at pointers, but there is no RDBMS that is as fast as Sleepycat DB v4. RDBMS is tuned for entirely different uses that a mail server would need. Changes require new delivery methods and dedicated access methods. POP doesn't cut if for me for that. Other ways to do it? IMAP servers. It's an open protocol that lets you maintain a variety of state flags about the message, move messages around into folders and lets you keep the messages on the server for location independant mail reading. Did I say it's Open? I use Mutt and Mozilla and Mulberry and Evolution to access it. Outlook can do it. And I've used ones that scale massively (a tad more than the 800 or so that an Exchange box can handle - or, folks are learning with slightly more scalable Exchange 2000 that the machines that they can reclaim from Exchange service are now needed for ActiveDirectory. Ooops.) But the qpopper advantage is that I can use POP, or tools that manage a System 7 mailbox. Quoting Gregory Hicks ([EMAIL PROTECTED]): > > > Date: Fri, 05 Apr 2002 15:17:01 +0200 > > From: Jesus Cea Avion <[EMAIL PROTECTED]> > > > > Problem: > [...snip...] > > > > Solution: > > > > A simple and efficient database (key/value) used to store messages. > > This is a solution that is commercially available and has a good many > customers. The software integrates nicely with many current desktop > apps. Comes complete with built in calendaring and appointment system. > Unfortunately, it only *nicely* uses ONE mail reader... It has the > potential to use many readers but deliberately does not integrate at ALL > with any of the others. > > The name of this commercial package and the reader? Exchange and > Outlook... > > The rest of your idea, though, are good and seem well thought out... > > Personally, I don't like the idea of keeping messages in a database... > >From experience, it is way too hard to guarantee good backups and thus > be sure that you will get a usable restore... Of course, that might > just be the product being restored...
