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: Mailet API v2
Date Mon, 03 Jun 2002 15:50:51 GMT
> Yes, I want to see mailet processing made available to applications that
> might like to use email but don't want the hassle.

> If your app would like to send mail, let James take the strain.
> If your app would benefit from recieving mail, again let James take the
> strain.

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.

> > Seems to me that a "container" has a port, a protocol, and a server
> > (processor) -- I am using these terms at a level of abstraction.

> > I'd find it more intuitive to see mailets associated with the SMTP
> > newslets with an NNTP server, etc.

> I believe that this would unnecessarily constrain the mailet API

Not at all.  Mailets are as ignorant of such details as they can be given
the level of abstraction in the API (it remains to be seen how much a
Newslet differs from a Mailet in terms of the semantics of the news vs mail

> Of course my grand plan is that it would be just as simple to add mailet
> functionality to anything

I understand.  I was trying to give the abstract notion of such a container.
But I don't think that you'll want to embed the container in the
application.  More likely, you'll embed (part of) the application in the

> You might want to build a huge and dynamic set of local delivery rules for
> mail, with heirarchies and precedence, priorities, configurable  and
> behaviours, you don't need to use James to do both if you have a dedicated
> mailet container elsewhere, protected from DOS and hacking, which collects
> its mail from James and uses James as its SMTP gateway.

Sounds like a particular configuration of James.  How does it differ?  James
is nothing more than a mailet container with protocol handlers, content and
user repositories, matchers and mailets.

> Or your application might be an intranet with shared calendars, and a
> application which would be able read and generate icalendar messages, but
> you're not allowed to run your calendar application in James (your boss
> let you, its not policy), so you run it using the default mailet container
> in whatever platform your boss spent all that money on last year.

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?

> After all a good API need be nothing more than a coherent collection of
> rules enforcing a pattern and offering interoperablility.

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.

	--- Noel

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