james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron.Kn...@vodafone.co.nz
Subject RE: JAMES SMTP API sub-project proposal
Date Fri, 22 Nov 2002 01:43:57 GMT

Hmmm.  I don't mean to be argumentative, or to divert JAMES off on my own
private development direction, but I do not believe that my goals in any
way conflict with the current JAMES project goals.

Basically, my goal is to receive and process mail in-process with my own
app, as simply as possible and with as little overhead as possible.  JAMES
appears to provide all of the building blocks required to do this - they
just need to be extracted (which doesn't seem all that hard).

I will comment on both Danny's and Noel's replies, here.

the goal of the James project to provide James as a complete solution, not
a set of components.

Yes, ok.  The JAMES project, as a whole would still produce a complete mail
server, assembled from a set of components, which would include those
provided by Avalon and those provided by JAMES sub-projects.

modify the handler for incoming SMTP such that it could be extended by
"verb classes" to support new SMTP verbs.

Unless I misunderstand you, this would allow for custom extensions to the
SMTP protocol.  This is not the goal that I am aiming at.  I want to avoid
having to have a separate process, with the implied inter-process
communication, for receiving mail.

I believe that the approach desired by James would be an embedded Mailet

If I understand the distinction you are making, then this would involve
embedding a much more heavy-weight component than necessary for a lot of
cases.  Correct me if I am wrong, but this would mean both an SMTP listener
(for receiving the mail) and a mailet container for processing it would be
embedded.  That would give you all of the mailet chaining stuff, etc. but
this is not necessary in many cases (although I do not deny that it would
be useful in many others).

I think that your original goal, to facilitate projects that
need to receive and process in-board e-mail, is something to support.  I
just disagree with your initial proposal to solve that problem.

I am open to suggestions.  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.  Perhaps your tuple-spaces idea could be used to aid with
this?  Have James receive the SMTP connections and write it to a persistent
spool, and have other apps able to receive that mail and process it by
reading mail from the spool - a kind of publish/subscribe scenario?  I
haven't thought about this one very hard, but it seems to dovetail nicely
with your massively scalable distributed JAMES idea from last week.  I
still think that an embeddable SMTP interpreter would be useful in addition
to this, however.

a mailet containing spoolmanager entirely self referential apart from
standard Java & j2ee classes, this again would form the basis for an
embeddable mailet container and mailet development suite.

Again - this might fit with the tuple spaces thing.  I think it is a good
thing.  I don't thing it precludes the embeddable SMTP listener from being
a good thing, too.

>From the design objectives listed on the JAMES web site:

Protocol abstraction Unlike other mail engines, protocols are seen only
like "communication languages" ruling comunications between clients and the
server. Apache James is not be tied to any particular protocol but follow
an abstracted server design (like JavaMail did on the client side)

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.  In order to achieve this, a clear interface
must be defined for JAMES to interact with different protocol
implementations.  Does this not mean that I ought to be able to utilise the
same interface to interact with a protocol implementation from another app?
It seems to me to be a small step from protocol abstraction to protocol
re-use - and in no way contra to the design goals of JAMES.

Certainly, I can see why you might not want to incur the administrative
overhead of a separate sub-project.  To me, that is not important.  It
would be enough to package protocol implementations as separate jars.  This
would also facilitate the development of alternate mail transports for
JAMES, perhaps allowing JAMES to receive mail from a JMS queue, instead of
an SMTP connection.

What I am proposing ought to make JAMES a more flexible a more widely
applicable product.

I am keen to hear the views of anyone that has an alternative approach to
suggest, here.




There is no magic.

                    "Noel J.                                                             
                    Bergman"             To:     "James Developers List" <james-dev@jakarta.apache.org>
                    <noel@devtech.       cc:                                          
                    com>                 Subject:     RE: JAMES SMTP API sub-project proposal
                    Please respond                                                       
                    to "James                                                            

> I have come across several projects with requirements to receive and
> process inbound mail.


> Currently, the options for implementing this (in java) are a JAMES mailet

Yes.  You could put a custom mailet into James, and communicate with the
application.  And please note that in a shared environment, you must do
because you cannot have both a real mail server and an application
on the same port.  This may not be an issue for you, but I thought I'd
it out.

> However, I would like to have a third option of embedding
> a SMTP listener into my application.

I believe that the approach desired by James would be an embedded Mailet
Container.  If you want to work on THAT, I believe that you'll see support.
And, in fact, it would be a very timely topic for Mailet API v2.

The rest of your message is premature and, in my personal view,
If you want to propose an embedded Mailet Container, and then talk about
what it will take to create one, I think you'll see more support.

Do you understand the difference?  Because I don't want to discourage and
dismiss you.  I think that your original goal, to facilitate projects that
need to receive and process in-board e-mail, is something to support.  I
just disagree with your initial proposal to solve that problem.

           --- Noel

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

Have you seen our website?.... http://www.vodafone.co.nz

CAUTION: This correspondence is confidential and intended for the named recipient(s) only.
If you are not the named recipient and receive this correspondence in error, you must not
distribute or take any action in reliance on it and you should delete it from your system
notify the sender immediately.  Thank you.

Unless otherwise stated, any views or opinions expressed are solely those of the author and
not represent those of Vodafone New Zealand Limited.

Vodafone New Zealand Limited
21 Pitt Street, Private Bag 92161, Auckland, 1020, New Zealand
Telephone + 64 9 357 5100
Facsimile + 64 9 377 0962

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