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 14:27:19 GMT

> It seems that you are thinking of using James as something other
> than a mail
> gateway.  Can you elaborate on what you're trying to do?


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.

If you want to have extensive mail functionality available to your
application, but *not* on the same box(es) use James.

> 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 server, newslets with an NNTP server,
> etc.

I believe that this would unnecessarily constrain the mailet API, of itself
it only really requires spooling and repository services to be provided. And
as such it seems to me that the spool manager is the ideal location for it.

Of course my grand plan is that it would be just as simple to add mailet
functionality to anything, NNTP in particular, and indeed to applications
which don't provide conventional mail services.

You might want to build a huge and dynamic set of local delivery rules for
mail, with heirarchies and precedence, priorities, configurable  and default
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.

Or your application might be an intranet with shared calendars, and a mailet
application which would be able read and generate icalendar messages, but
you're not allowed to run your calendar application in James (your boss wont
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..

After all a good API need be nothing more than a coherent collection of
rules enforcing a pattern and offering interoperablility. Even though I
advocate distributing a number of implementations of mailet interfaces its
implementation can legitimately be the concern of the user.




d.


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


Mime
View raw message