Matthew T. O'Connor wrote:
> I don't understand the desire for a rewrite. Perhaps I'm missing > something, but DBMail isn't just some quick prototype someone scratched > up one night, its a good system that already does a lot of good things. > There certainly are rough edges and things that can, will and need to > improve, but don't throw the baby out with the bathwater. And why > would you want to take a nice tool written in C and move it to python? > Nothing will be as fast as a well written C program. The present code is *very* slow when working with headers (including fetches and searches) in large folders. And the problem is, the present code may not accomodate the addition of some storage extensions that are necessary to make it fast. Staying with C might be OK if there are enough standard libraries to do the things that need doing, AND enough developers to actually write well-documented and readable code in it. I have seen such code, but not in large quantities. There is nearly no such code in dbmail now, making it quite hard to modify. And modification *is* needed. The present setup is so slow on big folders that, for me, the system becomes unusable. > > Let's not take the path of 'enlightenment' then, heh. Full backward > > compatibility where possible, small steps. > > I think this is expressing the same sentiment that I was above. Please > don't make massive drastic changes that result in dbmail changing more > than improving. I want it to improve, get faster and more efficient, > nothing would be better. I think this is where the consensus is. Dropping the system entirely and writing from scratch is a possible idea. This is what the mplayer team did - they support and improve the current code, but their main thrust is now on mplayer G2, a new framework to which some of the old code gets "ported". But, I don't think anyone here wants to go this way yet - the current userbase is an asset, and the working pop/imap code is another. But - much depends on Ilja's / IC&S's position. If a dialogue with the other developers fails, there is one more possible direction of movement for those who want better database storage. Joining some actively developing IMAP server, like Dovecot, and adding a database backend. If the present code is dropped entirely, this may be more feasible than a total refactoring. The dovecot.org page says: "I have also plans to support storing mails in SQL databases." So there's another place where we (I, and perhaps Paul?) can go, and develop a mail storage for a ready-made IMAP system. But Dovecot is a big C-language project with its own rules; I, for one, would not be ready to code in that (I can document, test, prepare table structure, write queries - but not code). Notes on Dovecot. I've looked at that code now. Dovecot has a much better coding style than the current dbmail version. But, it uses C to the max to optimize for speed, even at the cost of code size and complexity. Its parser for IMAP FETCH actually has a "case" on the first letter of the FLAGS/BODY/etc, instead of immediate string comparison! A major advantage of Dovecot is a clear, and well documented (!), separation of the mail storage layer. It even has a search function. Writing a database storage plugin for Dovecot could not be easier - except for the fact of the C language. I would estimate that if C is the language of choice, adding a DB storage engine to Dovecot might be way easier than refactoring current C code in dbmail; and the mime parser is already there. The large (larger than dbmail) userbase, the well tested POP3/IMAP daemon code (no SMTP), and the really well thought out design are all there. The desire to add the functionality is also there. It's not my preferred direction, because I would not be able to participate in the coding; but it's a possible direction. Paul? Yours, Mikhail Ramendik
