Aaron, I would like to propose an alternative to more complex configuration. My proposal allows the Mailet configuration to be kept relatively simple, as in other proposals, but still provides support for more complex configurations such as you've described.
My proposal is a resource-based model. I will explain this model in J2EE terms, although were there some decision to use Avalon lifecycle methods in the Mailet API, we could invert the pattern. In either case, the same thing happens: the matcher or mailet gets a resource. The key is that we keep this out of the Mailet API, and use standard Java APIs. This is a good thing, in my view. Are you familar with JNDI resources? Basically, we can define a resource in the config.xml file. The resource is basically made up of a class and other parameters. A JNDI lookup is used to get that resource. So for a matcher or mailet requiring a complex configuration, we use the simple configuration to tell it the name of a resource that it should use. Elsewhere in the config, we establish that resource. See the tomcat docs: http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jndi-resources-howto.html. The implementation is not difficult. We can take the work that Serge has already done for the JNDI DataSource, and extend it generically with little additional effort. And if we run into an implementation surprise (not expecting one), code for all of this is present in Tomcat, a sister project. For the simple, native, configuration format, I support the proposal for which Danny recently posted the DTD. You can see how we can easily tell a matcher or mailet to load a resource containing more complex content. And advantage is that it enables modular configuration, separating those complex configurations, instead of keeping them in-line. Please give some serious consideration to this proposal. It covers more than just config. If we adopt it, we have a simple model for extending resources to matchers and mailets without a change to the Mailet API, and without imposing artificial limits on flexibility. --- Noel --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
