james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sid Stuart <...@weaselworks.com>
Subject Re: Supporting multiple "root processor"s in James 1.3?
Date Mon, 21 Apr 2003 02:49:24 GMT
Noel J. Bergman wrote:

>You are engaging in a fiction.  There is absolutely nothing magical about
>the ROOT processor.  There is no "tree", non-looping or otherwise.  ROOT is
>simply the default entry point for new messages, whether created internally
>or spooled via the SMTP handler.  All that I'm contemplating is adding a
>convenience method and a new XML element to override the default.
>
First off, let me say, I agree with what you are contemplating. I think 
it is a good idea. It is a part of what I was proposing in the letter 
that started this thread. I was using the phrase root processor to mean 
entry point as I thought that would make more sense to the reader. 
Apparently I was mistaken.

>>The problem is it is not obvious whether a mailet
>>sets a new processor queue and which processor it
>>does call when defining the XML tree.
>>
>>The Mailet that does this is called ToProcessor.  Quite obvious, except for
>>the ones that cause messages to start over at ROOT.
>>
Yes, I understand the function of the ToProcessor mailet, it is 
transparent in what it does and I have no problems with it. The concern 
I was expounding on (poorly) was the method defined in the Mail 
interface called setState(String state). My understanding from previous 
discussions is that this method allows the mailet to redirect the 
processing to a new processor. My concern was that this adds obscure  
connections to the graph that would make loops hard to see/debug. My 
suggestion was to change setState to be a non-argument method that would 
pick up the value of the new state from a parameter in the configuration 
file. This would make it easier to see/debug infinite loops, should they 
occur. It would also allow the names of processor's to be changed 
without requiring a recompile of any mailets that use the method. (Not 
that I am suggesting that any processor's be renamed, heaven forbid. :)

>>I very much believe having multiple root processors that
>>act on messages with different attributes (spooled,
>>delivered, dead-letter...) to be a big win.
>>    
>>
>
>Minus the misleading term "root", my configuration is already pretty much
>that way.  All of the tools are already present.
>
Okay, to use your terminology, I think there should be different sets of 
directed graphs defined in the config file and a mechanism provided to 
initiate processing by the matchers/mailets of one of those graphs on 
different sets of messages: those that are being delivered (already 
exists), those that have been delivered and those that have ended up in 
the dead-letter repository. If I understand your proposal to provide 
multiple entry points correctly, that will allow different sets of 
directed graphs to be defined in the config file. So that will solve 
half of the problem.

The other half is to have the capability to select a set of messages to 
run through one of those graphs.
If the tools to do that exist, would you please point me to where they 
are documented, because I have missed it. Better yet, if you could give 
an example of how to solve Mr. Smith's need to reinsert dead-letter 
messages back into the system, it would help both him and me.

>By the way, you keep referring to James 1.2 and 1.3.  We're shipping v2.1.x,
>and planning version 3.
>
Yeah, I have a hard time with numbers, something to do with being 
slightly dyslexic.  My apologies for the mistake.

Sid

Mime
View raw message