Danny, > > - How would we add a Matcher/Mailet? > > Update the configuration, rebuild the mailet chain and send > init() to the > > added mailet. > > We need to have a graceful way to stop the spooler and > processors without mail being abandoned between mailets where > some processing related to a task (processor) has occured but > not all of it.
Yes. We would have to stop processing new mail and wait for in-process mail to complete processing. Once the system is 'drained' we could go ahead with the reconfiguration. When reconfiguration is complete, we can resume processing mail. > > > - How would we remove a Matcher/Mailet? > > Update the configuration, rebuild the mailet chain and send > > destroy() to the > > removed mailet. > > ditto above, the problem being when we pause mail destined > for a removed mailet, where does it go when we resume. Wouldn't happen if we drained the system as described above. > > - How would we modify a Matcher/Mailet? > > Update the configuration and send refresh() to the modified mailet. > > > > Only two new concepts are introduced here, an updateable > configuration and > > the addition of the refresh() method to the Mailet and > Matcher interfaces. > > I'd rather call it reconfigure() Then the init() method should be called configure(). > > Adding the refresh() method to the Mailet and Matcher interfaces > > would break > > pre-existing code. > > Not if we declare it in another interface which mailets can > optionally implement and only offer reconfiguration to those > that do support it. That's what I tried to describe. GenericMatcher and GenericMailet could implement the new interface and provide a stub method that does nothing. > > So, dynamic reconfiguration of the Transport Matchers and > Mailets could be > > achieved more easily than full dynamic reconfiguration which > > requires Avalon > > support, but not without a fir amount of effort. > > The effort is the big stumbling block. Agreed. > > I am not sure what the demand for dynamic reconfiguration is. Its > > great for > > developers in a code/test/fix cycle, lethal if abused in a > production > > environment but sometimes a life-saver. > > I think it is most in demand for production, where small > mailet pipeline config changes shouldn't require us to stop > the IO protocols. > Perhaps we want to change the destination of a "forward" or > something else "operational" > > In fact it would also be nice if we could reconfigure things > like DNS, Postmaster address etc. Yes, anything that doesn't require a change to the Avalon environment. > > Maybe others would wish to comment on if its worth the effort? > > Big effort but ultimatly YES worth it if its done well. Hopefully once there is a clear idea of how it should be done we can break the effort down into smaller do-able pieces. -- Steve --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
