> - 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. > - 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. > - 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() > 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. > 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. > 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. > > Maybe others would wish to comment on if its worth the effort? Big effort but ultimatly YES worth it if its done well. d.
