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: JAMES SMTP API sub-project proposal
Date Fri, 22 Nov 2002 03:22:13 GMT

I did not take your messages as argumentative.

> I do not believe that my goals in any way conflict
> with the current JAMES project goals.

Your GOALS are not the issue.  It is your choice of METHOD that is
questioned.  The primary area of concern on your part is that you seem to
believe that an embedded mailet container needs to be a heavyweight item.
That is not the case, IMO.

There is no reason why a mailet container cannot be a very lightweight item.
If you can accept that as a normative statement, then we can work towards a
common solution that is satisfactory to all.  I know that this is one of
Danny's goals, because he has talked about quite often on the list.

> I lean away from your embedded mailet container
> in the form that I have described it above, due
> to it's being too heavy-weight.

Then help us to define it otherwise, if that is your concern.  :-)

You may not realize it, but your timing is perfect.  As soon as we ship
James v2.1, we're going to design the Mailet API v2.  As part of that, your
project will prod us to really look at what it takes to be a mailet
container.  Your example is a lightweight, micro-container.  James provides
a mediumweight container, which we can scale larger.  So I view this as an
indication that the timing is right to take a serious look at how we promote
mailet containers.

> Perhaps your tuple-spaces idea could be used to aid with
> this?  Have James receive the SMTP connections and write
> it to a [tuple-space.  It] seems to dovetail nicely with
> your massively scalable distributed JAMES idea

> an embeddable SMTP interpreter would be useful in addition
> to this, however.

Let's raise these issues in the context of the Mailet API v2 design work.

> This, to me, seems to imply that JAMES should be able to receive and send
> mail via a number of transport protocols, which in turn implies protocol
> abstraction and pluggability.

Protocol handlers are pluggable items that are decoupled from message
handlers by queuing interfaces.

> Certainly, I can see why you might not want to incur the administrative
> overhead of a separate sub-project.

Speaking for myself, if the sub-project is a lightweight, embeddable, Mailet
Container, I believe that the project is willing to incur the administrative
overhead because that is something expressed as a desired project.

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