Aaron Knauf wrote:
I disagree, but rather than go into the why's and wherefore's here, I will finish off the UML that I am working on to ensure that we are not just misunderstanding each other. I will however, say this:Ok sure, just as long as it's not in the mailet API or specification, that's cool with me.
I think that access to some form of structured config for mailets is important.
Plugability of config implementations is not something that needs to be reflected directly in the Mailet API, but can be a value add for a particular container implementation. (Like ours!)
Dynamic reconfiguration must be supported by the configuration subsystem if it is to exist at all. Someone listed this item on the wiki as being a desirable for V3. It is quite a lot simpler not to do it.
Yes, I think dynamic reconfiguration is a must.
IMHO, the key to doing this successfully is to provide a system that is simple by default, but powerful for those that wish to put in the effort and dig a little deeper. Log4J is an excellent example of this concept. It takes a 4 line config file and single line of code to get basic logging to work. However, if you want more, you can make your logs get up and make coffee!I agree, and I think your log4j reference is a good example of what I'm shooting for... let the application developer do whatever he or she wants using all the options available with Java. I'm just looking to provide rules for a mailet container, i.e., how you could write some Java to process email messages. This doesn't need to (and shouldn't IMHO) include much about logging, databases, configuration, etc...
So I like to keep it lightweight and focused on the specific problem of email processing. Also when in doubt about the appropriate level of complexity, I tend to fall back on whatever the servlet API deemed appropriate. Servlet apps haven't shown much limitations with that API (either too advanced or too lightweight), and it's fostered numerous implementations.
So for the sake of Mailet API and specification, if in doubt, leave it out. Then figure out a way how a specific mailet container like James could offer the necessary features on its own.
--
Serge Knystautas
President
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
