james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Serge Knystautas <ser...@lokitech.com>
Subject Re: Processor naming thoughts?
Date Mon, 14 Apr 2003 17:26:13 GMT
Noel J. Bergman wrote:
> I agree with the idea of renaming setState to something else.  But I am not
> quite convinced that renaming processor to queue will have any beneficial
> impact.  The first thing that I think we could do is demonstrate better use
> of processors within the stock config.  I've made changes here, for example,
> to separate out error, spam, and relay-denied mail.  We could further factor
> out, within reason, the mail process to give people a better example of how
> to use processors.  As it is, we pretty much have just root, transport,
> error and spam.
> The tradeoff is that the current architecture is optimized for fewer
> processors.  LinearProcessor is pretty tight, but there is overhead going
> through the spooler.  However, I think that we can address that issue, and
> the benefit of better understanding for the majority of users outweighs the
> optimization needs that more expert users can achieve.

I agree we could use more examples, more documentation, better examples, 
all would be great.  The work you and Peter did to better document 
leading up to the 2.1 release has really helped increase the community 
(the board notes that were just committed included this same credit to 
you and Peter.)

Your note made me realize, however, it's technically not even accurate 
to say we're sending it to a processor... if you call setState(), that 
saves the message in another queue, and eventually the processor will 
get to that message, my point being it is asynchronous.

I'm not suggesting we should drop the processor notation altogether... 
mailets are processors, we would still have a LinearProcessor, and James 
is fundamentally all about message processing.  But I think it also 
helps mimic other messaging standards/conventions to speak in terms of 
queues (or sometimes called channels), and then have handlers or 
processors act on those messages.

Serge Knystautas
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com

To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org

View raw message