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: New Mailet API - Was Re: what competition is doing
Date Tue, 03 May 2005 19:02:17 GMT

Good ideas.  However, you might want to review the Wiki and mailing list for
a lot of similar ideas that have been worked over already.

> As I've been porting the SMTP protocol handler over to MINA

We should talk about that, soon.  I am contemplating if that is really the
right place to do it, or if we should do it in the connection support code.
Benefits to each way.  Please see my discussion with Trustin regarding how
the servlet API was mapped to NIO, and the subsequent code changes in MINA.

> - Mailet staging - It would be really nice to be able to have different
> stages for mailet execution.  The first stage would start when the SMTP
> DATA command is received.

Mailets are designed to be used after a message is received and ready to be
processed.  We can talk about some other pluggable component for use inside
of protocol handlers, as appropriate.

> This would also make it possible to reject the incoming message

Please do not confuse matchers and mailets.  There is also the idea of using
a the Matcher interface within the protocol handlers, to better implement
flexible fast-fail.  We have some code already available for that, which we
can look to deploy now that we have the merged codebase coming together.

> - Mailets as deployable units

Most things should be deployable.  Matchers and Mailets are container
managed components.  We need to decide on exactly what/where the container
is.  I have suggested that the Mailet container is the processor, and we can
have different processors with different capabilities and even different
Mailet Api versions.  Keeping this analogy, if we might look at a
classloader with the container, so tearing down the processor like a web
app.  The issue there would be handling currently unique things, such as how
the new mailing list manager code works.

So something to give serious thought to, and then implement.

Also, I would like to see spooling and scheduling pulled out of the
matcher/mailet and into the container code.  That way we can have
RemoteDelivery type scheduling, but for other things, such as DNS retries,
etc.  The spool interface should handle it, but we need to do some code and
config movement.

> - Multiple mailets per matcher.

Been on the list for ages.  See the Wiki for some proposals.  But this is
really quite trivial to do today.  Just use a processor.

> - Process to allow mailets to run for a non-match.

I think that's also on the list for the more advanced config.

Again, I really like the ideas you are coming up with, and your enthusiasm.
I'm just saying that there is a lot of prior discussion on much of these
sorts of topics.  More discussions than volunteers available to do the work.

	--- Noel

To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message