> Standard (supported) access to mail repositories (in any form). +1 this is on the agenda
> Improved Mailet deployment. Hot deployment is a nice-to have, but not > essential. What is essential is for me to be able to build a simple > deployment unit that is easily inserted into JAMES in a clear and > defined manner. +1 this too is on the agenda, I've been looking at new Phoenix classloader +configuration classes, this gives us/you the opportunity to configure classloaders +(in otherwords class paths & jars) fron an xml file. In theory we can use this both +to build a default mailet classloader path, and allow "power users" the ability to +alter this to include/exclude jars and paths. > Improved Mailet configuration. Pluggability of config sources, in > particular. I would like to be able to get my config from (variously) a > RDBMS, an XML file, or the JAMES init params. again +1, there has been talk for *ages* about the desirability of "hot" reconfiguration of the spoolmanager. I would like to allow processors to have their own configuration, in seperate files, and have these files discovered by james at runtime, much like tomcat discovering context configuration files. I would like to think that we could abstract this so that James would know how to look for processor configurations in different configuration loaders, but I'd be cautious about how popular this feature would actually be, particularly if the real problem is dynamic re-configuration, and is already addressed. d. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
