> > What about a "test" mode so that changes could be
> > validated/tested before
> > being put on-line?
>
> I've no idea how this might be achieved on a 'live' server. Any ideas?
Forgive me if I get my James internals & terminology wrong <g>.
As I understand it, messages essentially go through a sort of pipe (root
processor) that directs them through the matcher chains, and possibly
redirects to another pipe (processor) etc. etc..
Could we (for test purposes) create a new pipe ("test"
processor...equivalent to root), but have a special way that messages enter
that new pipe rather than coming from the SMTP spool. This new pipe would
essentially be parallel to the root processor (same matchers and mailets)
and there'd be parallels for all the other processors too.
I guess that could cause a lot of overhead for some of the mailets etc. as
they'd be loaded twice, and maybe there'd be some design limitations that
might interfere with this approach.
With the test pipe running, we'd have a way to inject various test messages,
be able to view their passage through the matchers/mailets (debug mode of
sorts?). Once the admin is happy, they could then commit the changes, and
that would perform the temporary stop on the SMTP spool then call
reconfigure once the changes had been saved.
...hmmm...
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
