> I believe I see the problem here. We are in danger of violent > agreement. It appears that you are talking about a Mailet container > whose implementation characteristics have very little in common with the > current JAMES server. (Other than the handoff of a mail object to a > mailet class.) Are you proposing that a framework be provided that > would make the writing of a custom Mailet container a relatively simple > exercise? Or that a lightweight container actually be implemented? I > would certainly be happy with either of these.
Actually both are under consideration, I believe that the changes we're (actually not!) discussing will make writing a container easier, *and* that we may then well produce such a container and a standalone run-time for it as a mailet test-bed for developers to use to de-bug their mailets. Potential features would be for the container to run *usefully* in a debugger and to process mail placed manually in a file-system spool, neither of which are exactly possible with James. d. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
