Dan Weber <[EMAIL PROTECTED]> said: > > Aaron Stone wrote: > > >Your goals sound really good. But as for the plan... Are you forking > >becauseyou want a different code structure or because you want a > >completely independent project that is not going to be compatible with > >mainline DBMail? > > > 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. 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. > >After 2.0, we're planning on changing the database structure to better > >handle header and mime caching, as well as a few other refinements. > > > >I'm more than sure that people here would like to see a "libdbmail.so" that > >exposed the message delivery and retrieval functions, and still have those > >functions be shared with the real DBMail to maintain compatibility. > > > >Don't fork to add features that people in the mainline want, too. > > > > > I need to remind myself to cleanup the headers so you can setup an > include distribution for writing extensions to dbmail. Essentially any > person could write their own filtering system as a module to dbmail. > This will finally allow for a dbmail-common package in debian which is > heavily needed. I think its getting pretty ugly and so is the rules file ;) 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. > >Aaron > > > > > >Dan Weber <[EMAIL PROTECTED]> said: > >[snip] > > > > > >>... I started working at this because I plan to fork dbmail > >>as soon as it hits a solid 2.0 release. I was going to split it more > >>into a mail management system and take away the pop and imap. Then I > >>would provide libraries and headers to write frontends to it. > >> > > > Online management of the databases directly through libdbmail.so and a > GUI api interface would probably be popular. > > Dan Weber > --
