Leif Jackson wrote:
I wan't to pose a question about the message cache code in the
imapd which is giving me some serious issues, any reason dbmail shouldn't
convert to using GCache (glib) and think about using GMime for message
parsing,
http://spruce.sourceforge.net/gmime/.
GMime in my research last night ( and early this morning) would allow us
easy access to all the header variables with resonable high performance to
do the header caching code in the delivery and then allow for re-parsing
for the imap code. I am going to be tring it maybe today in my quest for a
thread safe imapd, it is not easy :/
I'm already working on rewriting the retrieval chain for imap using gmime for
message parsing.
Mostly just a lot of work. I've recently dumped rfcmsg.c and dbmsgbuf.c completely, starting message parsing
from scrach. Refactoring that code was just too painful. There are limits. Doing so means having to rewrite a
lot of the imaputils.c code to get rid of msgbuf_buf and friends in one big move. Which is also good.
I've got a really good feeling about gmime, and haven't found anything yet in the current message handling and
mime code not already solved in gmime or easily implemented using gmime as the toolkit.
Also, rewriting the imap code to use gmime means I don't have to understand the current code, which is a boon.
I just have to understand rfc3501 :-)
But I also would like to establish an api for dbmail's handling of messages. And for that my current thinking
is geared toward a DbmailMessage struct which contains not just the message_id and stuff, but also a reference
to a GMimeObject as the actual full message, a GHashTable of all headers, and possibly a GHashTable of
relatively expensive parsed information like BODYSTRUCTURE. I wasn't aware of GCache. I will sure look at it.
Once we have messages wrapped in a DbmailMessage struct, and put the imap-session in a DbmailImapSession
struct (did that already in the nfg-0-1 branch), we just got rid of all globals that make the current imap
code non-thread safe (afaict).
Dynamic header caching will then also suddenly become a whole lot easier to
implement.
Thanks,
Leif
p.s. I don't expect any of my patch to be accepted however I belive that I
am doing a resonably good job and would be glad if parts of it were
considered to be incuded.
Don't sell yourself short. I havent seen any crap code coming from you yet.
For all in dbmail land you know I have been
lurking on dbmail-dev ...etc for a long while and have only contributed a
little up till now, I have a reson for all this code work as I have a
contract pending a proof of concept for dbmail that would put dbmail on a
200+ node cluster (w/ mericom..etc.) and do some serious mail, obviously
even with pthreads it won't run on the cluster with any reasonable
usablity
200+ node eh? Very nice. Any bottlenecks we don't already know about?
but the idea is to look into the thread safeness of the code and
then be able to extend it into a modular system...etc all in concept right
now but I thought it would be nice to at least give the proof of concept
code back to dbmail and see what you all will use/like from it.... havn't
had much sleep sorry rambling...
I for one am looking forward to more of it :-)
--
________________________________________________________________
Paul Stevens mailto:[EMAIL PROTECTED]
NET FACILITIES GROUP PGP: finger [EMAIL PROTECTED]
The Netherlands________________________________http://www.nfg.nl
