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 MailRepository
Date Thu, 14 Nov 2002 02:28:45 GMT
Hi All,

I am new to this list, but not new to JAMES.  I have been developing 
against JAMES 2.0a1 and I have a few observations regarding the design 
of the mail repository system.  I understand that things have changed 
since 2.0a1 and I would like to try to ensure that future JAMES version 
upgrades are as painless for us as possible, as our reliance on JAMES is 
becoming deeper.  I recently posted on the james-user list and it was 
suggested that I join the dev list - so here I am.  If my understanding 
of JAMES is out of date, or just plain incorrect, please forgive me.

Here goes:

I think the JAMES mail repository needs to be exposed to mailet authors. 
  At present mailet authors must import packages from Avalon and from 
JAMES code that is not in the mailet jar file in order to manipulate 
mail repositories.  This introduces a dependency on an internal 
implementation, which creates problems when that implementation change 
in the next release (which is exactly why I am still working with 2.0a1).

Our requirement is this:
We would like to be able to define an arbitrary mail repository, store 
incoming mail into it and process that mail asynchronously.  (I would 
like be quite clear that I have no interest at this point in the 
physical implementation of the repository.  Whether mail is stored in a 
RDBMS or the file system or under the mattress is of no consequence.)

It strikes me that two approaches are available here:

1) Expose the MailRepository interface in the mailet jar file and 
provide a standard way to get a reference to to a particular repository.

2) Expose the ability to define mail repositories through config.xml 
*and also to process the mail in them*.  At present there is the 
ToRepository mailet to put mail in a repository.  The trouble is that 
nothing happens to the mail once it is written to a repository.

A combination of both is the best solution, I believe.

As I understand it this is the way it works right now:

1 - Mail is received by JAMES and written to the spool repository.
2 - The spool manager reads mail from the spool repository and passes it 
to a processor, giving the mailets their chance.
3 - A mailet may pass the mail to another processor, or to a repository, 
or not.

I am thinking that this could be extended to include the ability to 
define a processor that is associated with a named repository.  This 
processor would have its own spool manager that read mail from the named 
repository and passed it to the processor for processing.  Or perhaps it 
would be better to define the repository as being an active repository 
and associating a processor to handle the mail from that repository. 
(i.e. repository references processor, not processor references repository.)

If all of this could be done declaratively, through config.xml, that 
would be vastly preferable to having to write code to create all of the 
necessary repository instances, spool managers, threads, etc.

A major problem with manipulating repositories in code is the 
requirement to cast Mail to MailImpl in order to use the repository. 
The repository interface should deal with Mail objects.  (An internal 
cast to MailImpl is also undesirable because I should be able to 
substitute one Mail implementation for another - that is what interfaces 
are for.)

The ToRepository mailet performs this cast at the the moment.  This 
(IMHO) demonstrates that the design is not right.  Should a servlet have 
to cast a HttpRequest to a container-specific HttpRequestImpl?  JAMES 
mailets should be able to survive with the same mailet API that everyone 
else's mailets work with. We need to be able to eat our own dogfood here.

I realise the at the moment all of this repository stuff is considered 
internal to JAMES.  The point that I wish to make is that I think it 
should be exposed.  I have tried to suggest a approach to this.  Right 
now my approach is not very carefully thought out and probably has 
plenty of holes in it.  Please try to see the spirit of this suggestion, 
rather than the holes.



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