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
- Re: TMDAemon cmulcahy
- Re: TMDAemon Jason R. Mastaler
- Re: TMDAemon cmulcahy
- Re: TMDAemon Jason R. Mastaler
