It does not appear to me that readyexec would work 'out-of-the-box.'
Much of TMDA's config-parsing, and as a consequence, its namespace comes as a side-effect of the import of Defaults.py. Readyexec's author seems more concerned about the expense of imports than the initialization of the interpreter, and I infer ( albeit w/o direct experimentation ) that all imports are performed at the initialization of the readyexec daemon/socket, thus denying the runtime per/user configuration that is one of TMDA's strengths.
If readyexec is not a 'quick-fix', it begins to lose its luster. While it is a quick'n'dirty way to achieve the basic socket-client/server architecture I am pursuing, the decisions made in the design of a short-lived script ( particularly with respect to memory usage and access to shared resources ) might not be appropriate for a long-running program.
Most importantly however, daemonization has the potential for ( perhaps as yet unforseen ) collateral benefits. A long running daemon can maintain ( a pool of ) persistent database connections, and engage in cooperative IPC with other daemons on hosts, local or otherwise.
Such a daemon's long-running state would allow it react on a system-wide scale. For example, once "[EMAIL PROTECTED]" is known to be a non-routeable address, it could be black-listed system-wide for a specific period of time, avoiding the overhead of queue-ing thousands of bounces or confirmation requests should 'kojo' hit the maildirs of 1000 or so TMDA-enabled users over a 24-hour period. Such a feature is vapor-ware ( and perhaps ill-conceived ) but the point is that daemonization makes future development of this sort possible.
mulc
Jason R. Mastaler writes:
"cmulcahy" <[EMAIL PROTECTED]> writes:
Do you feel this is better than the ReadyExec method I mentioned? Ifhello 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.
so, why?
That's what I figured.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.
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.You should be working from the CVS source, not from a past release. See http://tmda.net/bugs.html. TMDA (in CVS) no longer uses rfc822. _________________________________________________ tmda-workers mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-workers
_________________________________________________ tmda-workers mailing list ([EMAIL PROTECTED]) http://tmda.net/lists/listinfo/tmda-workers
