> 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 seems to me that Mailets are trying to provide an infrastructure for glueing together various modules that handle mails, and provide some order to the universe. If I go away and write my own set of classes that have nothing to do with mailets then I've lost that order and commonality that makes glueing bits together flexible. That's why I think it's important for Mailets to be able to call other Mailets. Trying a list of Mailets in sequence (LinearProcessor), is one pattern for dealing with things. But it's a bit like a programming language that has sequences, but no iteration or conditionals. It will solve problems that fit that paradigm, but is not turing complete. Let's say I have a Mailet that will ftp attachments to a server. Say I have another Mailet that forwards attachments to someone. Now let's say I want a Mailet that will try and ftp the attachment but only if that fails, I forward it instead to an address. So what I want to do is glue two mailets together with this third Mailet logic that decides under what circumstances to call these other Mailets. Now I can see this could be done with James by having three processing pipelines and using this goto idea, but imagine instead we want to utilize 10 different Mailets with really complex decision making and it would be quite convoluted I think. >>* 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. Because you want one stage in the pipeline to pass parameters to later stages in the pipeline. For example, let's say you've got that ftp Mailet that ftps attachments to a given server. And lets say that ftp Mailet takes as argument server name, user name, password and directory to dump the file in. So you could put those arguments in the XML config file. But let's say you want the directory name to be today's date. It's not static, so you can't put it in the config file. What you want to do is write an application specific Mailet that decides what the directory name will be and pass it onto this ftp Mailet. (BTW, this is a real scenario I've had to deal with). >>* 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. It's not clear to me how you would get access to the alternative spooler, but I'll take your word on it. >>* 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. I'm thinking it would have to be something like.. <PARAMETER name=myvariable>myvalue</PARAMETER> That way you can enforce a DTD. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
