Danny, > I spent this w/e reviewing the Mailet API
Would you please annotate http://wiki.apache.org/james/JamesMailetV3? For that matter, would folks PLEASE update that or http://wiki.apache.org/james/JamesV3/Plans as necessary? I was looking at copying the suggestions from the mailing list, but I would really prefer that everyone took the time to do that themselves. > the processor and repository interfaces and a couple of implementation > methods from James to Mailet. I don't think theres anything contentious > in my ambition, I'm not proposing archtectural changes and have carefully > considered everyone's input into our earlier discussions. I don't know about processor. I think we ought to go back and look at a processor being a mailet. > I don't think there's much reason for doing JNDI or API changes in any > particular order, save that I'd like to have a specification which > specifies the role and beaviour of JNDI first. My specific point about order is that there are things that we might add to the API that might be done, instead, by pluggable services that are accessed via JNDI. > I merely want to make processors the basic element of auto-deployment, as > they seem to strike a nice balance between size and flexibility. I would also like to see dynamic reconfiguration. > The only change I will propose is that LinearProcessor be allowed to not > terminate mail so that unhandled mail can fall back through. As I've said to you before, that was NOT a change that Peter put in. We simply changed how it was done. The original code added All and Null to the end. We replaced that with explicit classes so that you would know that it had fallen off. I would be happy to see several new attributes added, as we did on[*]Exception. I had wanted to add a class attribute, but that might not be necessary (not if we do end up switching back to Mailets as processors), and could agree with requiring an explicit end clause for processing. Again, this whole area might change depending on the mailet as processor approach. > > > $) 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. > Agreed. I don't think it'd be a big job, but it's been outstanding for > *so**long* I think it has to be on someone's worklist this time round. I am not sure that it has been outstanding. A lot of people who ask for virtual hosting don't realize that we already have it, or think that they want something else. --- Noel --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
