james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noel J. Bergman" <n...@devtech.com>
Subject RE: [PATCH] mailet API
Date Fri, 06 Dec 2002 16:47:38 GMT

If what we are trying to say is that the revised Mailet API will still run
existing Mailets that abided purely by the prior Mailet API interfaces, I
think we're in agreement.  I see no reason to break that compatibility.

I think that most of the radical surgery within James will be in specific
areas of the internals.

	--- Noel

-----Original Message-----
From: Danny Angus [mailto:danny@apache.org]
Sent: Friday, December 06, 2002 11:02
To: James Developers List
Subject: RE: [PATCH] mailet API

> In what sense?  A mailet that uses the new Mailet API won't be capable of
> running on older versions of James, and an older mailet that goes
> beyond the
> Mailet API and accesses Avalon resources directly may not be able to work
> after introducing a portable solution.

But an older mailet that *doesn't* go beyond the existing API will be able
Just because some do doesn't mean that all do.

There's no reason why James shouldn't support both versions, and some
compelling reasons why it should.

> Do we want to continue to permit this:
>     ComponentManager compMgr =
> (ComponentManager)getMailetContext().getAttribute(Constants.AVALON

No, we dont, this is already established since idontknowwhenthehellago as
you well know.

> Maybe ... maybe not.  I think we have a lot to discuss, and I wasn't
> planning to make any a priori assumptions.

By which standards peters documentation shouldn't be making any claims about
the API changing or not.

I merely thought it would be prudent not to propogate the impression that
the API was about to undergo radical surgery that would break everything
that has gone before.


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