> Are we to consider releasing James with Merlin instead > of Phoenix for instance..?
I'm considering what we've been considering for over a year: migrating from the old version of Phoenix to the "current" version of Phoenix in our CVS, and the current Avalon components. Phoenix is a proven and stable platform for us, but if someone wants to give Merlin a try, that's fine. My take on the container is that we it to just be there, support our code, be free of memory leaks and crashes, and otherwise stay out of our way. > My own plan.. and in this order.. > a) Revisit the Mailet API experimental changes, particularly those > which haven't found favour. > 2) Add JNDI support for service and parameter lookups to the Mailet > API wordy spec (and draft it as it doesn't exist!) and implement > same in James I agree, but would reverse the order. Having JNDI in the Mailet environment will impact what we can expose, and how, which will impact discussion and consideration of what should be added to the Mailet API, itself. > Add support for archived application auto deployment, probably on the > basis of deploying "Processors" . Tighten classloader separation and > add JNDI local contexts for secure separation of processors. I think we should revisit processors and mailets again, as we started to discuss earlier in the year. > $) Add flexible virtual hosting. Offering a choice at config time of > either IP based using bound IP's or name based using rich account names. I think we already have this, or are very close. We might want to record our collective ideas on the wiki, where we already have others: http://wiki.apache.org/james/JamesV3. Looks like we've already done some, and have new ideas on others. Serge would probably suggest, and he's right, that we start to use JIRA to layout our roadmap concretely. --- Noel --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]