james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noel J. Bergman" <n...@devtech.com>
Subject RE: JavaMail as the message store
Date Mon, 03 Feb 2003 15:51:04 GMT
Danny,

Yes, the proposal is to use the JavaMail interfaces instead of the
MailRepository interfaces, which were not in Mailet API until a few weeks
ago, as you know, and would be rolled out.  However, you appear to be
missing a key point.

> I happen to like the ideas expressed here earlier [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.

Using JavaMail isn't instead of alternative file formats; it is the
consistent means by which we access and implement them.

The proposals to do that from Serge and myself are based upon using
JavaMail.  JavaMail doesn't provide us with a canonical storage format.
JavaMail provides API and functionality built on top of service providers.
One type of service provider is a storage provider.  There are storage
providers for mbox and maildir, for example.  Serge proposes that we also
take our existing storage implementations (Avalon repository and JDBC
repository), and adapt those to use the JavaMail service provider interface.
By using the JavaMail storage interface, we can access any of those formats.

                        JavaMail
                           |
      ---------------------------------------------
     |        |            |             |         |
   mbox    maildir    Avalon File    JDBC store    etc.

In summary, JavaMail facilitates our use of multiple storage formats, adds
functionality that we need on top of those formats, and allows us to
leverage more resources effectively.

Does this make more sense, now?

	--- Noel


-----Original Message-----
From: Danny Angus [mailto:danny@apache.org]
Sent: Monday, February 03, 2003 6:04
To: James Developers List
Subject: RE: JavaMail as the message store


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



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