> 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 to. 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 > _COMPONENT > _MANAGER); > 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. d. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
