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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
