james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Hammant <Paul_Hamm...@yahoo.com>
Subject Re: [Mailet API] Logging Proposal
Date Tue, 11 Jun 2002 21:28:50 GMT
Dave,

>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.
>  
>
+1

>(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).
>  
>
That includes me.  We have _working_ HSQLDB working as a block.  Jo! 
Webserver as a block (Cataina in some days).  EnterpriseObjectBroker as 
a block.
Other teams are doing work on a multiple impl Authentication block. 
 Others still are making a JMS block.  Stephen on the Avalon-apps 
project is making a CORBA ORB block.

There is no reason why a MAILET thru the Serviceable API could not 
lookup anyone of these.

>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.
>
-1.  That is what Phoenix is for.  Classic provision of different 
services.  A particlar MAILET when packaged with some of these blocks 
for a bespoke need, could be interoperation (publishing) to a web page.

Hell, A different MAILET could be using Cocoon for rendering of an 
XSP/XSL html-email page that is sent as the body of an email.  The 
Cocoon team have stated they you like to be able to run outside of 
servlet context as a rendering engine.  They have done the abstractions 
already, just noone has made the block wrapper. V.cool.

>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.
>  
>
-1 again dude.  Not a maillet, a block.  Design is finished, no need for 
hacked container impl

>Hope this helps.
>  
>
A quality posting.

-ph




--
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