On Aug 29, 2008, at 12:51 AM, Paul J Stevens wrote:
Uwe Kiewel wrote:
Hi,
is there any roadmap for moving dbmailv2.3 to the production
status? I
expect, it will be dbmail v2.4.
There is only my 'internal' todo list:
- fix threadsafety in the server core.
- tls/ssl support (finish and integrate Jake's work ?).
- improve imap compliance, esp under high concurrencies (tweak).
- integrate other contributed patches (tweak).
Nice!
post-2.4:
- add support for hybrid/multiple backends; project 'octopus'.
- add support for archive-mode (implies support for stepped deletion
of mailboxes).
But to be honest, the first todo is somewhat of a puzzle atm. That
is mostly
because I'm trying very hard to avoid mutex locking as much as
possible. It
mostly means cleaning up and decoupling a lot of datastructures,
which means a
lot of work but pretty straightforward refactoring.
In the case of gmime however, the mimeparser's core datastructures
are in
essence singletons (the GObject type system is not threadsafe) and
require a
global mutex lock. This means there can never be more than a single
GMimeParser
in-core. This sucks in terms of performance. Fixing that will
(probably) require
chucking gmime altogether, and replacing it with something threadsafe.
Ouch, that sucks pretty badly. Have you been in touch with the Jeff
Stedfast about this?
libSieve is also not yet threadsafe. I've been very slowly working on
refactoring the parser to use reentrant flex/bison. Slowly being the
operative word there :[
Aaron
_______________________________________________
DBmail mailing list
[email protected]
https://mailman.fastxs.nl/mailman/listinfo/dbmail
