On Thu, 27 Sep 2001, Serge Knystautas wrote: > I don't like making the mailet API tied to the Avalon structure. I'm > hoping mailets and matchers can eventually become used enough that other > mail server engines start supporting them.
Think about James mailets which would have reached the critical-mass sometime in the future... in effect, developers would write mail-servers based on Avalon. You'd get credits from the Avalon team. > Another idea would to leave the GenericMailet as is, but then also offer > a GenericAvalonMailet that would have easier access to Avalon > information. I'd probably be +0 on this since it does in effect > encourage people to write non-generic mailets. I may just be > unrealistic in this hope though. I believe that would be too much; besides, it would complicate the documentation. > The RemoteDelivery mailet already grabs Avalon resources, which it does > by grabbing a ComponentManager from a MailetContext attribute. Seems > like this approach could give you similar access to Jdbc sources or > whatever. I plan to rewrite the Town alias and Town listserv without > Town (using the internal jdbc datasource), and I'll see if I can figure > a nice way to get these to work. Yes please; basically, all I need is to have an easy way to get a reference to Avalon's ComponentManager from my matchers/mailets. Well, I want to make sure that the compose() or initialize() methods in the mailets would get invoked too... Oki --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
