Re: [Dbmail-dev] Libtool + install cleanup

[Dan Weber]

The libtool gave some memory benefits which were quite nice. I personally don't think preforking will be very good in the end due to certain situations. If you have 70k users, they all ping up the imap/pop at the same time, its going to be eating a ridiculously large amount of resources and time with preforking. Especcially since its spawning a new process for each client, and it is also cloning the resources. This essentially will eat the living daylights out of memory. Pthreads seem to inherit resources and won't allocate new ones each time. They also seem to spawn faster and can get some nice benefits on SMP machines. Maybe I can find some time to submit some pthread patches to show.

Dan Weber

Dan Weber wrote:

Aaron Stone wrote:

Your goals sound really good. But as for the plan... Are you forking because

you 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.

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.


functions be shared with the real DBMail to maintain compatibility.

Don't fork to add features that people in the mainline want, too.

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

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 ;)

The sbin patch was necessary. When was the last time you saw a daemon that had to bind < 1024 in /usr/bin?

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

--
_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://twister.fastxs.net/mailman/listinfo/dbmail-dev

------------------------------------------------------------------------

_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://twister.fastxs.net/mailman/listinfo/dbmail-dev

signature.asc
Description: OpenPGP digital signature