- Mailets as deployable units
Most things should be deployable. Matchers and Mailets are container managed components. We need to decide on exactly what/where the container is. I have suggested that the Mailet container is the processor, and we can have different processors with different capabilities and even different Mailet Api versions. Keeping this analogy, if we might look at a classloader with the container, so tearing down the processor like a web app. The issue there would be handling currently unique things, such as how the new mailing list manager code works.
One thing that always bug me about webapps is how they restart. Why should there be any downtime? I'm going to have a new classloader and fully initialize it... don't tear down the first instance until the second is fully initialized, then cutover and hand new connections to the new classloader instance, and eventually the old classloader instance will finish handling those requests and can be GC'd. Does this bug anyone else?
The only reason I can't see doing this is if you were changing socket bindings, which neither servlets nor mailets should.
So something to give serious thought to, and then implement.
Also, I would like to see spooling and scheduling pulled out of the matcher/mailet and into the container code. That way we can have RemoteDelivery type scheduling, but for other things, such as DNS retries, etc. The spool interface should handle it, but we need to do some code and config movement.
Did we get anywhere with thinking JMS could do this? I'm pretty excited about ActiveMQ (http://activemq.codehaus.org/) which we could bundle, and then provide any JMS integration. Probably performance issues, but not sure.
Again, I really like the ideas you are coming up with, and your enthusiasm. I'm just saying that there is a lot of prior discussion on much of these sorts of topics. More discussions than volunteers available to do the work.
+1 as I am exemplifying. :)
-- 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]
