james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Danny Angus" <da...@apache.org>
Subject RE: JavaMail as the message store
Date Mon, 03 Feb 2003 11:04:13 GMT
Guys,

Bill and Alex notwithstanding if we want to implement javamail storage, should we not be doing
this *either* by implementing it compliant with Mailet, *or* first refactoring Mailet to take
account of requirements of storage implemented with javamail.

In the former case the javamail implementation would, by definition, work with the existing
mailets, and in the latter existing mailets and storage implementations would have to honour
the new contract. Thus the javamail implementation would, in both cases, be interchanegable
with exsiting implementations.

Or is the proposal to replace mailet interfaces with javamail ones? 

If so -1 because.. 

I happen to like the ideas expressed here earlier by myself and others, that we might pursue
a number of alternative file formats for mail storage in order to improve interoperability
and migration between James and popular existing software. This is not limited to MTA's. I
expect that there is a lot of mail processing software, virus and spam scanners for E.G. which
scan files in one or other of the common formats, and possibly even listservers which could
be allowed to run in conjunction with James if James used one of these formats.

If this proposal is to replace the exisiting repository implementations and re-write the repository
contracts in order to offload this responsibility to javamail then, like I say, -1.

d.

> In any event, my point about migration is simple.  We won't preserve two
> implementations of the mail repository for the interim.  But 
> during initial
> development, we don't have to change the spool implementation, 
> and we really
> don't need to change the ToRepository mailet, which is used to 
> dump spam and
> error in the stock configuration.  At the beginning, the only 
> things that we
> HAVE to change are the LocalDelivery and POP3 handler components.
> 
>   1. Change LocalDelivery and POP3 to use JavaMail stores.
>      Use one of the existing JavaMail stores.
>   2. Test, tweak, test again.
>   3. Change ToRepository Mailet
>   4. After the spooler is replaced, we can remove the current
>      mail repository interface.  As I understand it, we also
>      convert our implementations to JavaMail stores.
> 
> This incremental development is intended to make sure that we 
> have a working
> server throughout the entire process.


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


Mime
View raw message