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 07:37:37 GMT


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:james-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@jakarta.apache.org>


Mime
View raw message