james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter M. Goldstein" <peter_m_goldst...@yahoo.com>
Subject RE: JAMES SMTP API sub-project proposal
Date Fri, 22 Nov 2002 01:24:32 GMT


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

I don't mind some argument, and personally I don't find your goals to be
the problem.  It's the approach I find problematic and ill-advised.
> Basically, my goal is to receive and process mail in-process with my
> app, as simply as possible and with as little overhead as possible.
> appears to provide all of the building blocks required to do this -
> just need to be extracted (which doesn't seem all that hard).

This goal can be achieved with the current design quite simply.  No
additional APIs necessary or desirable.  To wit, run your app as an
Avalon component within Phoenix.  This takes advantage of a pre-existing
API that is both widely used and well tested - the Avalon Framework.
Have your mailet access your app directly, and communicate with your
custom API that's part of your app.  Piece of cake.  And it's something
that, in one form or another, we've committed to support in the next rev
of the mailet API.

I'd strongly suggest that you read the Avalon/Phoenix docs to get a
clear picture of how something like this would work.

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

Not sure why my reply doesn't merit a response, but I'll reply to this

> <danny>
> the goal of the James project to provide James as a complete solution,
> a set of components.
> </danny>
> 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.

Fine, although a sub-project would need to be justified first.  The
additional complexity of a sub-project would need to be justified by one
or another meaningful goal that are currently unachievable or difficult
to achieve with the current product.  So far I haven't heard any.

> <danny>
> modify the handler for incoming SMTP such that it could be extended by
> "verb classes" to support new SMTP verbs.
> </danny>
> Unless I misunderstand you, this would allow for custom extensions to
> SMTP protocol.  This is not the goal that I am aiming at.  I want to
> having to have a separate process, with the implied inter-process
> communication, for receiving mail.

You are correct.  Danny's suggestion really doesn't help for your stated
goal - mail processing in-process - unless you want to hijack the entire
SMTP dialog.  But allowing that capability seems to be part of the API
you suggest (see my earlier email) which I find extremely problematic.
There are right and wrong ways to do such things, and I'm pretty sure
publishing a public API where the consumer of the API is required to
assure RFC compliance is the wrong way.

> <noel>
> I believe that the approach desired by James would be an embedded
> Container
> </noel>
> If I understand the distinction you are making, then this would
> embedding a much more heavy-weight component than necessary for a lot
> 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.
> this is not necessary in many cases (although I do not deny that it
> be useful in many others).

This is not a correct interpretation.  The SMTP server component and the
mailet container are distinct components.  That's not an accident.

The SMTP server component is responsible for SMTP communication.  The
SpoolManager is responsible for mail processing.

> <noel>
> I think that your original goal, to facilitate projects that
> need to receive and process in-board e-mail, is something to support.
> just disagree with your initial proposal to solve that problem.
> </noel>
> I am open to suggestions.  I lean away from your embedded mailet
> 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
> 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
> 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.

See my comments above.  Everything you want to do is already doable.  No
need for additional sub-projects, API, or what-not.  The SMTP server
publishes messages to a spool.  The SpoolManager picks those messages
off the spool (publish/subscribe, in process) and sends them to the
first processor.  Your custom mailet, which does whatever you want it to
do, sits in situ and does whatever you want it to do (i.e. persist the
message to your own spool, deliver it via an API to a custom app, etc.)

> <danny>
> 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.
> </danny>
> Again - this might fit with the tuple spaces thing.  I think it is a
> thing.  I don't thing it precludes the embeddable SMTP listener from
> a good thing, too.
> From the design objectives listed on the JAMES web site:
> <quote>
> Protocol abstraction Unlike other mail engines, protocols are seen
> like "communication languages" ruling comunications between clients
> the
> server. Apache James is not be tied to any particular protocol but
> an abstracted server design (like JavaMail did on the client side)
> </quote>
> This, to me, seems to imply that JAMES should be able to receive and
> mail via a number of transport protocols, which in turn implies
> abstraction and pluggability.  In order to achieve this, a clear
> must be defined for JAMES to interact with different protocol
> implementations.  Does this not mean that I ought to be able to
> 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
> re-use - and in no way contra to the design goals of JAMES.

No.  The interpretation and drawn conclusion have nothing to do with one

One of James' primary purposes is to abstract away the RFC protocols
(SMTP, NNTP, IMAP, POP3) and allow administrators to do processing of
the message independent of the protocol.  It does this largely by
providing correct, robust, effective implementations of the RFCs.
Messages transmitted to James using these protocols are placed in a
protocol-neutral (...abstraction barrier...) spool.  The SpoolManager
processes messages on this spool, and allows customization through the
Mailet API.  That's what makes it an abstract server design.

> Certainly, I can see why you might not want to incur the
> 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.

No it wouldn't.  It would break abstraction barriers that are already
present and well respected by the code.

There's actually already a server component that demonstrates the
correct way to do something like this.  That would be FetchPOP.  It
grabs mail from POP3 accounts and drops it on the spool, to be processed
by the SpoolManager.  Change POP3 to JMS, and you're basically done.  No
need for some SMTP listener API.  It is not only possible, but easy, to
maintain this functionality while completely deactivating James' SMTP
server functions.

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

Nope.  It doesn't.  Just makes it less robust, violates abstraction
barriers that are well established, and introduces yet another API that
we'd be tied to.
> I am keen to hear the views of anyone that has an alternative approach
> suggest, here.

See above.


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