Danny,
> I'd rather eat my own leg than introduce namespaces into the config.
The API would not change, nor ever see namespaces. My intent was that
namespaces would ONLY be in the configuration file, not the Mailet API. The
Mailet Container might have some work to do, but that would be transparent
to the API.
In any event, as Serge pointed out, moving the matcher config to a child
element of the mailet allows multiple checks, which is why I agreed to the
other approach.
I don't have a problem keeping the name Matcher. If we did introduce a new
name, I'd consider the name "Selector" from the previous choices. Selector
could extend Matcher, since you seemed to want to introduce more complex
notions without losing the simplicity of the basic Matcher interface. I
don't know if that is at all necessary, just tossing in the idea.
> my problem with [user-specific pipelines] would be that it _might_
> mean that it becomes harder to predict the outcome of processing
> for an individual mail, in that the whole process is no longer explicit.
As I think on this notion further, the basic idea is simply to be able to
associate processors with criteria in a dynamic environment. Here is an
alternative expression of the same concept, which fits better with out
current approach.
We could provide selectors to see if there is a processing configuration
registered for a given criteria (sender, recipient, whatever), and support
the ability to load that pipeline and transport to it. The idea is that
where today I might have:
<mailet match="UserIs=u1@d1" class="transport">
<processor> u1proc </processor>
</mailet>
<mailet match="UserIs=u2@d2" class="transport">
<processor> u2proc </processor>
</mailet>
<mailet match="UserIs=...@..." class="transport">
<processor> ...proc </processor>
</mailet>
<processor name="u1proc">
...
</processor>
<processor name="u2proc">
...
</processor>
<processor name="...proc">
...
</processor>
we could have
<mailet class="Transport">
<selector class="RecipientHasProcessing"/>
</mailet>
The mailet doesn't tell us what the processing is. It simply says that at
this point in the current processor we want to see if there is any
processing configuration associated with each recipient. If so, the Mailet
Container is told that we'll be wanting the specified processing
configuration, and the message is put into the spool for processing.
Just for purposes of this example, I am working with the notion that
RecipientHasProcessing could communicate the target processor to the mailet,
and that the standard Transport mailet would support it, including the
implied demuxing. Similar selectors could handle other matching criteria.
I am defering further details on precisely how to implement the mechanism
because this hinges on being able to dynamically load processors from a
configuration description, and also on thoughts regarding the spooler and
processor types other than LinearProcessor.
I am sure that this idea will evolve further, and the code refactor, but the
basic concept of being able to associate processors with criteria in a
dynamic environment seems good to me.
--- Noel
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
