On 4/19/06, Noel J. Bergman <[EMAIL PROTECTED]> wrote: > > it introduces another dependency. > > I'd rather not introduce that dependency. HOWEVER, we have been talking > about the fact that we have much better support for multiple Mailet > packages, and I would be +1 to add this to an OPTIONAL mailet package. Just > not the standard mailet package. Fair enough?
I'll get some examples together on the wiki next week. I was looking at the method call, and realized that Mailet's service(Mail) is probably the most appropriate. I noticed then that the remaining methods are all related to lifecycle/configuration and potentially would get removed down the road. Same thing with the Matcher interface. This seemed interesting to me because it could make James very distributed... use this to create remote matchers and mailets, either to run business logic, or to transfer a Mail in a spool on one server to a spool on another server. -- Serge Knystautas Lokitech >> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
