james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Knauf <akn...@xtra.co.nz>
Subject Re: JAMES SMTP API sub-project proposal
Date Thu, 28 Nov 2002 11:14:37 GMT

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

Precisely the reason that I thought of using the SMTP dialog handler 
from JAMES - I don't want to shoot anyone.

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

I believe I see the problem here.  We are in danger of violent 
agreement.  It appears that you are talking about a Mailet container 
whose implementation characteristics have very little in common with the 
current JAMES server.  (Other than the handoff of a mail object to a 
mailet class.)  Are you proposing that a framework be provided that 
would make the writing of a custom Mailet container a relatively simple 
exercise?  Or that a lightweight container actually be implemented?  I 
would certainly be happy with either of these.

Things that I would not be satisfied with include:
Embedding anything as big as JAMES.
Embedding my app inside JAMES (well - Avalon).

How would you envisage that the socket listener bit fitted in?  Would it 
all be bundled?  How would its thread handling work?  (Would it have it 
own code for creating/managing threads, or would that be provided by the 
app embedding the container?  Or am I missing the point again?

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

Ok.  The making money statement comes across as pretty cynical.  The 
point that I wished to make was that *a* solution was provided to *a* 
problem, as opposed to *the* solution to *the* problem.

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

"basically undeniable" is a dangerous term to use.  Yes, Message Driven 
Beans fill a gap in the market.  No, they are not the only way to 
usefully implement a *real* JMS message driven application.  How can 
anyone possibly contend that?

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

And the SMTP dialog handler, which - as you have mentioned previously - 
is pretty difficult to write from scratch.

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




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