james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Knauf <akn...@xtra.co.nz>
Subject Re: JAMES SMTP API sub-project proposal
Date Wed, 27 Nov 2002 08:43:17 GMT
Ah ha!  It seems that the world has not stopped while I've had my head 
down over the past few days!

As far as extracting the SMTP API so as to re-use it goes - I might just 
   let that one drop.  As has been mentioned a number of times, it 
doesn't look like there is much enthusiasm for that idea.  C'est la vie!

Here are a few other ideas/viewpoints along similar lines as those 
previously expressed on this thread.  Some of these ideas are already 
provided in the current JAMES version.  I list them here because I want 
to express the features that I feel are important.

I would like to see several things come out of the v3 Mailet API -

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.

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

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! 
  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.  :-)

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



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

View raw message