james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Morris <dave.mor...@codon.demon.co.uk>
Subject Re: [Mailet API] Logging Proposal
Date Tue, 11 Jun 2002 13:56:29 GMT
A few ideas to add to the discussion ....

What about other 'services' which the container could/should provide.
Configuration being a case in point.

The avalon framework provides a rich configuration toolkit.
The current Mailet API restricts the configuration to name value pairs.

If you are going to add (or link) the avalon framework logging components to the
Mailet API, then why only add one part of the framework.
Surely, there would be a case for also adding the configuration components, and
possibly others as well.

So, the question becomes do we link the Mailet API to the avalon framework
components.
Not just the logging components, but logging, configuration and possibly others.

(I'm not suggesting that we should, just extending the scope of the question)

If the aim is to make the Mailet API general purpose, similar to the Servlet
API.
Then it might be useful to look at some simple and complex Servlets as possible
use cases.

To write a simple request/response Servlet, all you need is the stripped down
Servlet API.
No logging, no configuration, just handle the request and response.
One (theoretical) application would be a simple Servlet running on an embedded
device in a domestic appliance.
A web server in a fridge which responds to a HTTP request with an XML fragment
containing the current temperature.
No logging API required, because there isn't anywhere to log to.

For a complex content management system, have a look at Cocoon.
Cocoon is a whole framework on its own, providing a rich set of tools to the
components inside it, including hooks to the Avalon framework configuration and
logging components.

If we look at the Mailet API in the same way.
One (theoretical) application would be a simple Mailet running on an embedded
device in a domestic appliance.
Send an email to the fridge, and it replies with an email containing an XML
fragment with the current temperature.
No logging, as there is no where to log to.
No configuration, everything apart from IP address is hard wired in silicon.

On the other hand, for a full scale enterprise level messaging system, with JDBC
repositories, LDAP user repositories, mailing lists, multiple user aliases etc.
you need a rich toolkit including both configuration and logging components.

Perhaps there are three projects in one.
1) The Mailet API (equivalent to Servlet).
2) The reference server implementation (equivalent to Tomcat).

plus, people working to extend this to implement
3) An Enterprise scale mail management system (equivalent to Cocoon).

To be honest, I missed this distinction when I started working on my own
Mailets.
I saw the 'E' in JamEs and immediately started thinking in terms of a full scale
Enterprise system.
It is only really since reading the ideas and thoughts in this discussion that
the three distinct parts have become clearer.

Following the Servlet/Mailet analogy.
How about this :
1) The Mailet API is the absolute minimum required to process an email.
2) The current implementation of James as a container for the Mailet API, with
the required protocol handlers and basic storage, e.g. file based MailRepository
and SpoolRepository.
3) The Enterprise components (and here I would include things like the JDBC
Repository etc.) could live inside an EnterpriseMailProcessor, which _is_a_
Mailet.
Much like Cocoon _is_a_ Servlet, but also acts as a container for XML
Generators, Transformers and Processors etc. with its own configuration and
logging services. The EnterpriseMailProcessor Mailet would provide access to the
Avalon framework services such as logging and configuration required by a
complex Enterprise scale message system.

Hope this helps.
Thanks,
Dave







--
To unsubscribe, e-mail:   <mailto:james-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@jakarta.apache.org>


Mime
View raw message