hello all,
I am trying to rebuild TMDA as a multi-threaded daemon, that is called by light-weight C-clients. The idea is to avoid the overhead of repeated Python invocations & imports and allow TMDA to scale to large-numbers of users without break-the-bank hardware.
I have a C-client ( http://www.avenirsolutions.com/mulc/tmda-client.c )
and the skeleton of a multi-threaded server to talk to it ( http://www.avenirsolutions.com/mulc/tmdserver1 )
I have spent the last few days looking over TMDA's code-base and a fair amount of revision will need to be done to adapt it to this architecture.
The principal issues appear to be thread-safety and name-space.
The "Default" namespace is particulary sticky. I think perhaps that a global default namespace (/etc/tmdarc) could be implemented as a dictionary passed along with the connection object to each server-thread whereupon the thread uses copy.deepcopy() to create it own namespace for mutilation and per- user customization from ~/tmdrc files.
Also, in a long-running daemon we don't have the luxury of copying the entire-message into a string variable. I am planning on buffer-writing the message to a tempfile ( as iplemented in my code ) and noting the file offset ( fd.tell() ) after calling rfc822.Message(fd) to create the headers object. On subsequent delivery we can write our modified headers, fd.seek() to the previously noted offset and then spool the message body from there.
I've offered up what I've got so far. If anyone is interested in helping the more the merrier
mulc
_________________________________________________
tmda-workers mailing list ([EMAIL PROTECTED])
http://tmda.net/lists/listinfo/tmda-workers

Reply via email to