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 Thu, 28 Nov 2002 08:59:25 GMT

Aaron,

> I agree that having both the mailet container and Avalon trying to
> manage lifecycle would be bad.  But that makes it no less desirable to
> allow mailets to have access to Avalon services.  On reflection, this
> could as easily be achieved by having a Mailet that delegates its mail
> handling to another Avalon component.  I suspect that trying to wrench
> JAMES around to do this for me would not be good for me or JAMES.  (I
> wonder how easy it would be to write a generic handoff mailet?)

I don't have any idea what you mean by a "generic handoff mailet".  It
is trivial to write a mailet that uses Avalon components.  I described
(in some detail) how exactly one would do that in some of the earlier
emails in this thread.
 
> Unless I am mistaken, embedding a mailet container in order to run a
> single mailet would still involve configuring a root processor with an
> all matcher for my mailet.

You are mistaken.  Write your own container and no root processor is
necessary.  The processor tree is an implementation-dependent construct,
not fundamentally part of the Mailet API.  All the API dictates is that
the mail message being processed has a "state".  The associate of that
state with a spoolmanager processor is a product of the implementation.

> The "administrative overhead" I am refering to is the overhead of
> writing (and maintaining) a configuration file for the processor.  If
I
> don't need matchers and mailet chains, why configure them?

Then don't put them in your container.

> An I simply mistaken in my expectation that processors, matchers and
> configuration files are necessary to an embedded mailet container?

Bingo.  You are mistaken.

> > I'm not going to comment on the design issues that you and your team
may
> > face, except to say that backwards compatibility with your apps
should
> > not and cannot be a factor in our API design.
> 
> Of course not - that is why I have not made any attempt to justify or
> even describe my design.  It is simply not relevant.  What I am
talking
> about is widening the applicability of JAMES to include another
possible
> deployment scenario.  My personal view is that this is a generally
> useful thing.  (You obviously do not agree.)

I don't think the deployment scenario you describe is left uncovered by
the current API or any proposed API we're likely to come up with.  I
think I've been pretty clear on this one.  And I think the solution you
propose is extremely dangerous and underestimates the difficulty of
writing a correct, robust SMTP dialog handler.

To put this in some perspective, prior to this version James has never
matched the basic SMTP specification.  Even with version 2.1 there are
some known issues (minor bug in dot stuffing) and deliberate violations
(lack of support for certain SMTP commands) in place.

Opening up an API for any Tom, Dick, or Harry to plug in an SMTP
interceptor is roughly the equivalent of giving a six year old a loaded
pistol.  You know they're going to hurt someone, you're just not sure
who.  There is no way random users are going to be able to write correct
implementations.  It's just not going to happen.

The mailet API allows us to maintain a very strong and clear abstraction
barrier between the SMTP service implementation and the post-SMTP mail
processing.  That ensures that James administrators do not have to
concern themselves with the details of the SMTP transaction, while
retaining all of the mail-processing power.

> This is not entirely accurate.  As mentioned above, it is not really
> even relevant.  To me, this discussion is about the best way of
> embedding support for mail receipt into an application.  Your
contention
> is that I should embed an entire mailet container.  My contention is
> that I just want the minimum code possible to turn an SMTP
conversation
> into a Mail object.

And what exactly do you think is the gap between these two?
 
> Speculation about whether or not *I* need lifecycle support is
pointless
> unless you want to get specific to my own application.  (I can't see
why
> you would.)  Our point of contention is whether or not full lifecycle
> support is so useful that it precludes the usefulness of embedding
mail
> support without lifecycle.

The lifecycle is deliberately lightweight.  That's one big reason not to
incorporate the entirety of the Avalon lifecycle.  There is a complete
discussion of the Avalon lifecycle here:

http://jakarta.apache.org/avalon/framework/reference-the-lifecycle.html

To contrast the Mailet API lifecycle would include equivalents of phases
1,2,3,4,6, and 14.  These phases need not necessarily be separated in
the same way in the Mailet version, but I think there is general
concurrence that we need the same functionality.

So what would you toss away?  What phase is unnecessary?  Moreover, what
phase is expensive?  If your mailets are so trivial that they don't need
configurations, initialization, etc. then why begrudge a couple of
method calls?  If they do need one of those phases in place, then they
wouldn't be usable in some hypothetical Mailet API w/o lifecycle code.
What exactly is the benefit here?

> 
> >
> > Let's be clear - message beans exist because the JMS API was
> > insufficient to meet the needs of most applications.  There needed
to be
> > a way to bring message response under the management of the
container.
> > That's why message beans exist - it was a common problem that now
has a
> > standardized solution.
> 
> Hmmm.  Message Beans exist because J2EE server exponents figured that
> there would be enough interest to make them some money - not because
> they figure it was the only solution to the problem.  J2EE appservers
do
> not preclude the usefulness of other solutions.

Bah.  This is a ridiculously cynical view of an engineering problem.  I
could make exactly the same statement about SMTP, JSSE, or JMS for that
matter.  It would be equally cynical, equally true, and equally
irrelevant.

No one is contending that this is the only solution to the problem -
what is being contended is that it is a standard solution to a
recognized problem.  It was the act of providing a solution to the
recognized problem that generated money for the container providers.

The point remains that JMS was insufficient for the needs of real
applications precisely because it lacked any lifecycle support.  This is
basically undeniable.  Lightweight lifecycle support was added, and
suddenly JMS became much more useful.

What would we have left if we stripped away the lifecycle elements of
the Mailet API?  IMO, we'd basically be left with the MimeMessage class
of JavaMail.  So what would be the point of defining a more limited API?
What tasks would one hope to accomplish that could not be accomplished
with the JavaMail classes?

> >
> > In a J2EE container you do not have access to the raw message
stream.
> > That's because you give up low level access to the message in
exchange
> > for the power, good design, and control of a container.  All good
stuff.
> 
> Yes great stuff - but not a silver bullet.  Appservers are not the
> universal solution to all coding problems.  Unfortunately, they are
> treated as such by many people.  (I hear that there is even an
appserver
> about that runs in a mobile phone!)

Again, we're not talking about app servers.  We're talking about the
concept of a container.  Very different.  Please try and get clear on
this.  You do not (and will not) need an app server to run mailets.
What you will need is a mailet container.

--Peter




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