Serge Knystautas wrote:
----- Original Message -----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:
From: "Aaron Knauf" <[EMAIL PROTECTED]>
Hi Danny,
The format you suggest certainly allows for multiple matchers and better
matcher configuration. However, it still leaves us with unstructured
name/value pairs. There have been a number of requests for structured
mailet configuration.
I don't think the level of configuration you're proposing needs to be
included as part of the mailet container. IMO, the container should load an
application, and if the application has complex configuration, the
application should handle configuring itself. I think many of your
suggestions unnecessarily raise the bar for mailet container implementations
and is looking for more than just a container.
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.
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!
Cheers
ADK
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
