Re: JAMES SMTP API sub-project proposal

[Aaron Knauf]

Peter M. Goldstein wrote:

Similarly, in my mailets, I should not be _required_ to make my mailet
into
an Avalon block, but I would like to be able to.  (I guess this is
probably
harder than it sounds, but it would still be nice.)

This is actually a typical server anti-pattern.  Essentially, it ignores
the inversion of control idea.  Inversion of control inherently implies
a chain of command (and hence a top of the chain of command).   If you
have two managing containers (and hence two responsible parties) you
have two competing tops of the chain of command.  Ordering problems,
initialization and disposal issues, etc. result.  Very contrary to good
server design.

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

*Mailet Container vs MailListener*

My objection to having to embed the entire Mailet container is not a
particularly strong one - if I have to embed the whole thing, that

will

not
be the end of the world - but here are a few reasons:
    *    Using a mailet container implies configuration of

processors,

mailets, etc.  This is an administrative overhead that is simply
unnecessary if you are not using that functionality.

Uh, we still haven't identified this supposed "administrative overhead"
that you'd be able to dispose of.  I think we're on a snark hunt.  Take
a look at the spoolmanager code.  Ask yourself exactly what you'd cut
out.  And what exactly you'd gain.

You seem to be assuming that my objection is to the spool manager. This is not the case. Synchronous vs asynchronous mail processing is neither here nor there. I simply don't see the point in having additional code embedded in my app that I don't use - e.g. The processor code, the matchers, etc. If it does not directly contribute to meeting the business requirements, it is just more to go wrong.

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.

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?

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

    *    Writing to spool implies that you must provide a place on

disk

to
write to info.  Not the end of the world, but again - unnecessary.  An
in-memory spool manager implementation would help here.

No, it doesn't imply that at all.  As your 2nd sentence points out,
there is nothing to prevent you from implementing an in-memory spool.
Or a spool that provides storage in any other way you want (networked
file system, punch cards, audio-encoded, what-have-you).  Honestly, if
you really, really wanted to, you could write a spool repository
implementation that directly accepted messages from the SMTP service and
synchronously passed them to your favorite mail processing (be it Mailet
or otherwise) tool.  It wouldn't necessarily be a particularly good
idea, but you could do it.

The current implementation requires the above, but that's because the
James user and developer base hasn't had a compelling reason to develop
alternate spools.  If you want to, please feel free to write some local
filestore independent spool implementations.  That solves this problem.

Agreed.  This topic is a red herring.

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

From what I can tell, you've got a handoff from the James process to

your EJB engine that you don't like.  There are two realistic options to
address this - either deploy James inside your J2EE container or deploy
your J2EE container inside Phoenix.  Adding interceptor APIs at the
level you propose is not only unnecessary, but it doesn't actually get
you anywhere in solving this problem.

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.

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.

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.

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

Nope.  I still think this whole pov is wrong though.  I found the
"Mailets v3" email to be a much more interesting and productive email.

That's why I separated it out. I felt that those points were important enough that I did not want them drowned in this stuff. This conversation continues because I love a good design discussion.

:-)

ADK



--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>