You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Serge Knystautas <se...@lokitech.com> on 2003/04/14 18:07:27 UTC
Processor naming thoughts?
Watching some of the threads of people trying to understand how mailets
work and how messages get processed, I was thinking maybe we should
rename "processor" to "queue".
By changing the name from the verb (process) to the noun (queue), I
think it will help people understand what is happening. It seems one of
the big points of confusion is, "what does it mean to send a message to
a processor?" Instead, "send a message to a queue" seems more
understandable.
Also then on the mailet API we should change setState() to setQueue()
since that's what we really mean.
Any thoughts?
--
Serge Knystautas
President
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
Re: Processor naming thoughts?
Posted by Hontvari Jozsef <ho...@solware.com>.
setState was definitely confusing to me. It should be renamed to be
consistent with the term used for the processor/que.
----- Original Message -----
From: "Serge Knystautas" <se...@lokitech.com>
To: <ja...@jakarta.apache.org>
Sent: Monday, April 14, 2003 6:07 PM
Subject: Processor naming thoughts?
> Watching some of the threads of people trying to understand how mailets
> work and how messages get processed, I was thinking maybe we should
> rename "processor" to "queue".
>
> By changing the name from the verb (process) to the noun (queue), I
> think it will help people understand what is happening. It seems one of
> the big points of confusion is, "what does it mean to send a message to
> a processor?" Instead, "send a message to a queue" seems more
> understandable.
>
> Also then on the mailet API we should change setState() to setQueue()
> since that's what we really mean.
>
> Any thoughts?
>
> --
> Serge Knystautas
> President
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Processor naming thoughts?
Posted by Sid Stuart <si...@weaselworks.com>.
It might be useful to use the same terminology as other MTA's. Exim has
a similar construct similar matchers/mailets called routers. If
processor had been named routerTree or routers, I would have known
exactly what it did.
Sid
Serge Knystautas wrote:
> Watching some of the threads of people trying to understand how
> mailets work and how messages get processed, I was thinking maybe we
> should rename "processor" to "queue".
>
> By changing the name from the verb (process) to the noun (queue), I
> think it will help people understand what is happening. It seems one
> of the big points of confusion is, "what does it mean to send a
> message to a processor?" Instead, "send a message to a queue" seems
> more understandable.
>
> Also then on the mailet API we should change setState() to setQueue()
> since that's what we really mean.
>
> Any thoughts?
>
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Processor naming thoughts?
Posted by "Noel J. Bergman" <no...@devtech.com>.
> In another project involving message middleware we used
> "Pipeline" to describe a processor chain
That's the same way I've used the term with respect to James. The pipeline
is the overall flow. Processors are part of the pipeline.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Processor naming thoughts?
Posted by Danny Angus <da...@apache.org>.
> > Hi, to me a filter is something that takes an input, removes
> > something
> > and the rest comes out at the other side.
A Mailet matcher takes all the mail, removes that which does not meet the criteria and the rest goes into the mailet.
> > On the
> > other hand,
> > when I think of an Oil pipeline the term fits.
As Jason also mentioned its the "oil" metaphor I was thinking of. In another project involving message middleware we used "Pipeline" to describe a processor chain because messages are "Pumped" along the "Pipeline" although that example also had a "Source" and a "Sink" to pump messages between.
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Processor naming thoughts?
Posted by Jason Webb <jw...@inovem.com>.
After having programmed EzMLM & Qmail they both have a concept of small
bits of code doing things. They call it a pipeline. I wouldn't get to
hung up on the CPU definition of it, the Oil one is much better!
-- Jason
> -----Original Message-----
> From: Stephan Wiesner [mailto:stephan@stephan-wiesner.de]
> Sent: 19 April 2003 10:13
> To: James Developers List
> Subject: Re: Processor naming thoughts?
>
>
> Hi, to me a filter is something that takes an input, removes
> something
> and the rest comes out at the other side. Matcher is great
> for me, like
> in 'the Mailet is activated if the senders address matches the given
> pattern'.
>
> To the pipeline: I am currently reading Tanenbaums 'Modern Operating
> Systems'. So to me a pipeline is something like 'modern CPUs have
> facilites for executing more than one instruction at the same time',
> while the processes are executed one after the other. On the
> other hand,
> when I think of an Oil pipeline the term fits.
>
> Stephan
>
> Danny Angus wrote:
>
> >I think we should perhaps consider this..
> >
> >processor -> pipeline
> >matcher -> filter
> >
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: james-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Processor naming thoughts?
Posted by Stephan Wiesner <st...@stephan-wiesner.de>.
Hi, to me a filter is something that takes an input, removes something
and the rest comes out at the other side. Matcher is great for me, like
in 'the Mailet is activated if the senders address matches the given
pattern'.
To the pipeline: I am currently reading Tanenbaums 'Modern Operating
Systems'. So to me a pipeline is something like 'modern CPUs have
facilites for executing more than one instruction at the same time',
while the processes are executed one after the other. On the other hand,
when I think of an Oil pipeline the term fits.
Stephan
Danny Angus wrote:
>I think we should perhaps consider this..
>
>processor -> pipeline
>matcher -> filter
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
RE: Processor naming thoughts?
Posted by Danny Angus <da...@apache.org>.
Serge wrote:
> Watching some of the threads of people trying to understand how mailets
> work and how messages get processed, I was thinking maybe we should
> rename "processor" to "queue".
Yeah I struggled with nomenclature when I 1st looked at making changes to the Mailet API.
I think we should perhaps consider this..
processor -> pipeline
matcher -> filter
we currently have only one processor type, linear processor, but in theory there could be more, such as forking processor, as such I believe that "pipeline" is both more comp.sci and more accurate than queue.
I'm happy to see name refactorings as long as we use inheritance to deprecate the old names, and don't just kill them off.
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Processor naming thoughts?
Posted by Hontvari Jozsef <ho...@solware.com>.
"I've made changes here, for example,
to separate out error, spam, and relay-denied mail."
I cannot agree more. I have setup James several times, and the current
default configuration file is always disappointing, it lacks the most
obvious things, like separation of bounce messages and meaningful
notification messages.
I add that using the postmaster address as a default sender in the config
file is a really bad idea. This is a warm invitation for viruses. Actually
the sender should be default (at least in the config file) to
MAILER-DAEMON@... with null address. I guess the null address would require
a change in the notification mailet too, not only in the configuration.
----- Original Message -----
From: "Noel J. Bergman" <no...@devtech.com>
To: "James Developers List" <ja...@jakarta.apache.org>
Sent: Monday, April 14, 2003 7:13 PM
Subject: RE: Processor naming thoughts?
> Serge,
>
> 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.
>
> --- Noel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: james-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Processor naming thoughts?
Posted by Serge Knystautas <se...@lokitech.com>.
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
President
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
RE: Processor naming thoughts?
Posted by "Noel J. Bergman" <no...@devtech.com>.
Serge,
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.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org