On Thu, 07 Oct 2004 14:30:56 +1300 yuri <[EMAIL PROTECTED]> wrote: > On Thu, 07 Oct 2004 13:57:54 +1300, Nick Rout <[EMAIL PROTECTED]> wrote: > > > After Jim and Volker's email presentations, I've been thinking. > > > How hard would it be to write an MDA that stores mail in a database? > > > I'm thinking of something gmailesque, with labels and conversations > > > (threads) and stuff. > > > > > > Next, how hard would to be to write a mail client to use with this maildb? > > > > well to be sensible you would have a server that used sql as a back end > > and served it up over imap, thereby allowing almost any existing mail > > client to access it. > > But imap doesn't support all the gmailesque features.
which gmail features were you after? searching - imap does that. Not sure what else gmail offers myself. perhaps you can fill me in. >Of course, you > could have an imap feature that would present a view of the maildb > that fits the traditional folders paradigm to an imap client. I would > also want to make available a client that takes advantage of extra > features. > > > needs to be fast, c probably. > > How fast? Assuming another MDA like procmail does some of the spam > filtering etc, and adds headers that tells the maildb MDA what to do > in some cases, so the maildb MDA processes the mail after procmail has > done some stuff. I don't think delivering into a sql database is necessarily the hard part, but getting it out the other end in some semblance of order and at speed might be. if you are truly developing a dead end system for yourself only. then speed may not be an issue. However mail systems are usually designed for high throughputs. > > I'm thinking small here, home user. > > pop3.clear.net.nz -> fetchmail (on my PC) -> procmail MDA -> maildb > MDA -> mysql database. don't forget procmail can pipe to any program (including /dev/null) so if you write a program to take mail on stdin and deliver it to a database it will fit into your system. > > > > The mail client would ideally be a GUI app or a web app. I guess that > > > might need something like PHP? > > > > > > why restrict the clients to web based ones? there are fantastic email > > clients out there that use the established protocols, what you are > > suggesting changes the face of email, and is inflexible IMHO. Stick to > > > > 1. storing the mail in an effective manner > > 2. serving it up over a known protocol > > But known protocols lack some features I'm interested in. > as above, what features? > > if you want a web client, use an existing one like squirrelmail or build > > one in php (etc) that interfaces to imap > > > > > > > > How big a project would this be? > > > > enormous if you are expecting every mail client to intriduce a new sql > > based protocol. see above. > > Not every mail client. Just one for myself to use with _my_ mail database. > I want things like gmailesque conversations, with collapsable quoted > text, multiple labels instead of folders etc. > > Yuri -- Nick Rout <[EMAIL PROTECTED]>
