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: Mailet API v2
Date Mon, 03 Jun 2002 22:33:28 GMT
> Register with james.  When mail arrives (from or to you), the mailets will
> take it from there.  There is no need to tightly integrate an application
> into James' code, via some ad hoc protocol or RPC/RMI/SOAP.

Except that they can be much richer, and more appropriate protocols than

>  James
> is nothing more than a mailet container with protocol handlers,
> content and
> user repositories, matchers and mailets.

Actually James is a lot more than a mailet container, most of James is
concerned with spoolmanagement, repositories and protocols, and making
protocols comply with all the fine detail of all the relevant RFC's is no
walk in the park, even now there are still new compliance issues being

> Fine?  I get the main mailer to forward any or appropriate messages to my
> stripped version of James, running my calendar mailets, and do my
> processing
> there.  What problem do you see?

Your stripped version of James is running in a different JVM, it cant share
objects with your business logic without becoming "distributed" if your app
could instantiate a mailet context you reduce the complexity of the problem,
and mailets become an attractive solution to mail processing.

> True.  But at the moment there is a good deal of environment exposed to
> Matchers and Mailets.  ComponentManager, DataSourceSelector;
> various stores,
> repositories, contexts and configs; etc., not counting Mail and
> MimeMessage.
> I'm sure you realize better than most what it will take to remove
> all import
> org.apache.avalon.* and from matchers and mailets, not to mention
> org.apache.james, so that all that's left is org.apache.mailet.* and
> javax.mail.*.  Until and as that API is defined, I don't see any feasible
> decoupling of the Mailet API from Avalon.

I take your point, and agree that any decoupling may have to define a
repository interface and the context may have to provide some new services
for the mailets, but the API doesn't have to provide those services, just
define what is minimally required. it would then be up to implementations to
provde them , using avalon if the implementors want to.
Likewise none of the contents of the James transport mailet/matcher packages
would *have* to use context provided services, they would simply no longer
be compliant and not portable to complient contexts, but if the context
provided them in a compliant way it would be able to contain compliant
mailet applications as well.
Similarly a simple implementation of the mailet API wouldn't need to provide
the sophisticated variety of configuration options that James does.
In fact it would be nice to see the mailet API attract new users to James
because of its more sophisticated implementation.

As far as mailet API dependancies on james utility classes, that just
requires a simple re-factoring to deprecate the classes in o.a.james in
favour of identical classes in o.a.mailet.

I know that there is work involved in this, and I do still believe that it
is worth embarking on it.


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