Paul J Stevens wrote:
If you're going to do a rewrite, beware the second systems effect..
Had to look that one up :)
It's also probably why we wont go with twisted. It's a huge bloat.
Great stuff, no doubt, but a major framework is probably not what we
need to bring dbmail ahead. For me, dbmail is about storage of email
first and last. I'm not smart enough to conceive and implement the
ultimate mailstorage engine. But I can work on providing current
functionality in software modules aimed at extension and
customization. And export-tool for dumping a dbmail-database (or
selected subset thereof) would for instance be a nice warming up
excersize in accessing the current storage layout.
#> dbmail-export --user=somefool --folder="/" --recursive
--outdir="/home/somefool/Mail/"
#> dbmail-export --user=somefool
--folder="#Users/otheruser/readonly-folder" \
--outfile="/home/somefool/Users/otheruser/readonly-folder"
something along those lines.
I agree, this type of tool would be a nice addition to the current
dbmail utilities.
After that, replacing dbmail-smtp, dbmail-util and dbmail-user with
python-based rewrites could lead to a nice set of base-classes to
tackle the more complex task of replacing the daemons should we choose
to do so (or find someone crazy enough). However, eliminating the code
required by the stand-alone tools will have the added benefit of a
good spring cleaning in the source tree.
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.
Lofty goals are fantastic, but if they take forever to implement,
people will jump ship. A rewrite is an acceptable idea if it is
feasible in terms of development time and either provides a CLEAR
upgrade path from the existing software, or is backwards compatible.
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.
Matthew O'Connor
