Aaron Stone wrote:
Dan Weber <[EMAIL PROTECTED]> said:
Actually I was really only going to fork if things didn't go my way.
The mail management system idea I thought was pretty good, then you can
molt it to your needs. I never thought upstream would like the idea. I
could probably finish the code for dlopen later so you could easily swap
modules in and out without issues. I have been working on an ODBC
driver for this for a little while, I think I am actually getting
somewhere on it atm.
dl() is going to be critically important to making DBMail distributable. The
Debian packagers here have been real troopers in this regard.
using loadable libraries is high on our agenda too. We'd like to make as
many people as possible use DBMail, and for that, we need too make it
easily distributable.
Speaking for myself, hopefully Ilja will present the IC&S position, the only
thing that's been keeping us from bringing in some more exciting ideas is the
trouble we've been having getting my delivery code to play nicely with Roel's
mime parser. Each had some wrong assumptions that was breaking everything in
weird ways. So anything that wasn't an amazing fix for all things wrong with
those has been too much to think about.
Getting more exciting features into DBMail (e.g. Sieve support, advanced
IMAP features (shared folders, SORT & THREAD support)) is very important
for us. Those things will get more people to use DBMail, and hopefully
also will get us more developers.
One important thing though: We're unhappy with the speed of development
at the moment. This is (mainly) my responsibility.
I think we should agree on a release strategy after 2.0. I'm inclined to
think we should have shorter, smaller release cycles. We should not add
to many features in a cycle. For instance, I'd like to add Anton
Nekhoroshih's Oracle support.
Doing smaller, incremental updates to the stable version will provide us
with a smoother upgrade path, I think.
Yeah, once we're back into development mode I'm going to first get Sieve
working and then work on making it easy to use other methods, too. There's a
stub for a regex method that was posted a long while ago. It was integrated
into the database code and so didn't work well with the database code
reorganization happening at the time, but there's no reason not to bring it
back as part of the sorting subsystem now.
The sbin patch was necessary. When was the last time you saw a daemon
that had to bind < 1024 in /usr/bin?
Agreed, you have a very good point here.
This last one was something I had asked for on the dev-list a few times.
I'm not very experienced with autotools, and had no idea how to get it
to install in /usr/sbin by default. I'm glad someone has finally done
this now!
Ilja
