Aaron, > Standardised access to mail repositories. Whatever form that may take, > I would like to be able to read and write (and even query?) the mail > repository. I would also like to be able to define arbitrary > repositories - although doing this in via config files is probably more > useful than doing it in code. I would also like to be able to define > named repositories and reference them by name from my code.
Standardized interfaces for all James repositories is on tap for the 3.0 discussions. The other questions are somewhat more complex, but I'm sure we'd be willing to discuss feasibility. > Mailets should be (able to be) first class Avalon citizens, with access > to the same services, lifecycle support and deployment semantics as any > other avalon component. This should be done without requiring that they > be made into standalone components. (The current "put your mailet on > the classpath and reference it in the config file" method should still > work.) This could be supported by exposing the JAMES config as a (dare > I say it?) API that other components can use to register themselves as > mailets. (This is realy just an idea for discussion - I'm not even sure > it has merit, myself!) I'm not nuts about this myself. Basically I find this idea problematic because i) IMO, James should control the mailet lifecycle and ii) I personally have no desire to rebuild Phoenix inside Phoenix. This has actually gotten some discussion recently, both here and on the Avalon-dev list. Please take a look at those messages. > An embeddable way of handling incoming mail is desirable. I still don't > think an embeddable mailet container is necessarily the best approach. > Something that lets me accept a SMTP connection and spits out a Mail > object for me to do as I please with is all that I require. This means, > essentially, a mailet. However, a Mailet no more necessitates the > present whole mailet container shebang than does a JMS MessageListener! This just isn't true. It's precisely because simple listener mechanisms were so woefully inadequate for server applications (no lifecycle, management, etc.) that the concept of a "Message Bean" was introduced in J2EE. In fact, mailets are fairly analogous to MessageBeans. They are container managed objects that respond to asynchronous events. They maintain no request state. Can you think of any reason why a J2EE container would be required to add a new API that would allow interception of the incoming JMS message before it is passed to the container? Again, I still just don't get your objection to a mailet container. The "whole mailet container" is actually pretty lightweight. This concept that somehow it is critical to get ahold of the mail immediately as it comes in as opposed to a few milliseconds later when it is passed to the spool manager is beyond me. I just don't get what you think this achieves? Can you clarify? > I believe that the Mailet container could easily be a Mailet! > (Composite pattern.) Ooops - there I go again. Never mind I am wearing > my asbestos suit. :-) Nope. Again, you're not taking into account lifecycle issues, management, configuration, etc. All the hard parts of a server app. Everything looks easy until you try and do it. Building a mailet version of a mailet container would basically force you to move all the spoolmanager code into the mailet, as well as figuring out how to force the relevant lifecycle info through the more restrictive Mailet interface. And what exactly is this supposed to get you...? > I don't like the idea of reproducing (even some of) the Avalon Framework > features in a Mailet-specific clone. This smacks of re-inventing the > wheel. What is it about the Avalon Framework that makes it unsuitable > for adaptation to this use? (Or even use without adaptation?) Again, read my emails. I've already addressed this there in quite some detail. --Peter -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
