> * The means of transferring control between > Mailets of setting the state to a new processor > name seems to me to be a glorified form of > "goto".
I think it *is* a goto, and works in the simple cases. I don't see why your logic shouldn't be contained in a set of classes which have nothing to do with mailets, and a mailet used to pass mails to your process, and send results back to James. That way you could programme as complex a set of tasks as you wanted to. Think of the mailet as an event handler handling a specific mail "event" you can raise new events, let the event propogate, stop the event propogating, or ignore using events altogether and run some code. > > * It's not clear to me how you would pass > configuration parameters to another mailet > at run-time. Why would the mailets want to communicate? I don't think your example really explains that, are you saying that you think one mail should be able to infuence the handling of other mails? If so why not have a single mailet which could recieve commands as well as process mails. > > * It looks to me like the decision to use database > or file system to store mails is a decision > that is made at the very highest level If you want to handle mail in different ways for different users you'd use mailets, if you want that kind of control over local mail delivery write an alternative LocalDelivery mailet. > * I'm wondering, it looks like the XML design > of random config parameters probably prevents > specifying a valid DTD. This is Alpha code, it is probably possible to have a DTD covering the existing situation, but it would have to be maintained, and if it was published it would leave no room for mailet authors to add new parameters, and comply with the DTD. Alternatively it'd have to be be so loose as to offer scant benefit. How would you deal with the issues you raise? all just MHO, danny. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
