On Sun, 24 Oct 2004 14:10:28 +0400, Mikhail Ramendik <[EMAIL PROTECTED]> wrote: > Paul J Stevens wrote: > > > This may be THE critical question. If Ilja goes on with this code, then > > > it's worth refactoring (especially since a rewrite might mean losing > > > that). > > > > Perhaps even Ilja won't have any regrets if he can dump the current > > codebase. However, his input, and Aaron's > > as well, is critical in such a decision. And I also don't want to > > alienate the current userbase. > > Perfectly agreed. > > If Ilja and Aaron join the idea, it's definitely worth a run. And my > proposed name would be DbMail-ng. (As in supermount-ng).
First of all, as to the low output from my side: We're short on man-power here at the moment, which means I'm very involved with other projects at the moment. There's so much output from all you guys, that it's quite hard for me to keep up with all new ideas, code changes etc. I'm almost through reading all emails that piled up while I was enjoying a 1-week holiday in France. Here's my take on the discussion of whether or not to do a total rewrite: I'd like it to be a more gradual process. We need to be make the code simpler. Paul's GMime work is the perfect example for this. We make our code simpler by using other peoples' work. One could argue that ditching C and going with Python would simplify things a lot more. As much as I like Python, I don't think it would be worth the effort. However, I do think making python bindings to a dbmail-library would be very nice. If during the development process, every line of code (including things i added) will be replaced by something simpler, smarter, better and faster, DBMail will be improved, and that's our common goal, isn't it? Now that we're continuing to get more developers, we should look at the way that we're organized. We can divide ourselves into task-groups with the following responsiblities: * Documentation group: create and maintain user and developer documentation. * Database layer group: This group will focus on improving the database layer. Providing a solid interface * Delivery and retrieval group: This group will focus on improving and maintaining the delivery and retrieval code (this is the stuff Paul is currently working on). Division into these groups might make for a more stable database layer. Better focus on where to find speed etc. What do you guys think? I think this might decentralize core decisions somewhat more. I'm not implying that people should only work on one part of the code of course, but more that the responsibility for some code might be shifted towards groups of people. Ilja
