Steve,
Yup I forgot the the internals of Mailet are entangled with Avalon. I was on this list a couple of years ago advocating separations, and don't really want to go back into those discussions. When 3.0 is mooted, and backward compatability for mailets is not required, someone ping me :-)
- Paul
James relies on a set of interfaces to provide container services. Currently these are the Avalon interfaces. I see no benefit in replacing those interfaces with another set which would need to provide equivalent functionality. That just seems to be a lot or work for what exactly? What are the killer benefits?
How a container fulfils the requirements of the existing interfaces is open. They could be mapped to a wide variety of deployment environments. Rather than port James to a new set of "Foo" interfaces, why not implement Avalon's "Serviceable/Configurable/etc" interfaces to your own "Foo" environment, enabling you to port all apps. conforming to the Avalon interfaces?
Still, like any large body of code, James could probably benefit from
refactoring to better isolate dependencies, such as those on the Avalon
interfaces. This would make it more flexible, both within and without
Avalon. This is more important if James is viewed as a toolkit of mail
server components, whereas the declared view, as stated on the web pages, is
that James is an application.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
