Hi Serge,
I think that we are both on the same page here. Your Servlet API guideline
is a pretty good one, I think.
When it comes to the actual Mailet API itself, I don't intend to do
anything particularly momentus or far-reaching. Certainly I will be
discussing it on this list before wedding myself to any particular idea.
At the moment, I am leaning toward a very basic MailetConfig interface,
with a default implementation that provides name/value pairs. There would
need to be a cast from MailetConfig to BasicMailetConfig in order to get at
the accessor methods. I am thinking that this could be done in
GenericMailet - so that the Mailet author doesn't need to worry about it.
The only other standard MailetConfig impl would be a DomMailetConfig -
which provides a DOM tree containing the XML within the Mailet tag. (Or
possibly within a <config> child tag.)
This would provide, within the standard API:
Default to NVP at zero effort for the Mailet author.
Introduction of the concept of alternative mechanisms into the API, with
DomMailetConfig.
Requirement to implement two types of MailetConfig - but no requirement
to provide any further alternatives or to provide plugability.
Requirement to provide a way of configuring a Mailet via XML. This
would *not* tie the container to the whole config XML. A mailet might
be packaged with its own "mailet-config.xml" in one implementation,
while another implementation could save the XML in a DB (maybe in
xindice?) and allow editing via an admin console. I do propose to
provide a standard XSD to describe mailet configuration.
It would then be up to a particular Mailet container implementation to
provide ways for a Mailet to use other MailetConfig implementations if it
so desired.
I am not in love with the idea of a cast in the normal flow, however. I'm
still mulling that one over. I don't want to limit alternative
implementations with the requirement to return name/value pairs. Any
ideas?
A couple of alternatives for the API might be to provide:
MailetConfig cfg = Mailet.getMailetConfig();
and
org.w3c.dom.DocumentFragment = Mailet.getConfigXml();
or:
BasicMailetConfig cfg = GenericMailet.getBasicMailetConfig();
and
DomMailetConfig cfg = (DomMailetConfig)Mailet.getMailetConfig();
Hmmm. I can see various implications/drawbacks in both of these. I'm all
thunk out for now. I just wanted to get a few thoughts down. Feedback
welcome.
Cheers
ADK
--------------------------------------------
There is no magic.
Serge
Knystautas To: James Developers List
<[EMAIL PROTECTED]>
<sergek@lokite cc:
ch.com> Subject: Re: Configuration Subsystem (was
Mailet Configuration)
30/01/2003
05:04
Please respond
to "James
Developers
List"
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:
>
> 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!)
Ok sure, just as long as it's not in the mailet API or specification,
that's cool with me.
> 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]
-----------------------------------------------------------------------------------------------
Have you seen our website?.... http://www.vodafone.co.nz
CAUTION: This correspondence is confidential and intended for the named recipient(s)
only.
If you are not the named recipient and receive this correspondence in error, you must
not copy,
distribute or take any action in reliance on it and you should delete it from your
system and
notify the sender immediately. Thank you.
Unless otherwise stated, any views or opinions expressed are solely those of the
author and do
not represent those of Vodafone New Zealand Limited.
Vodafone New Zealand Limited
21 Pitt Street, Private Bag 92161, Auckland, 1020, New Zealand
Telephone + 64 9 357 5100
Facsimile + 64 9 377 0962
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
