Stefano Mazzocchi wrote:
>
> Federico Barbieri wrote:
> >
> > <match id="checkHeader=sender:[EMAIL PROTECTED]"/>
> >
> > I really think match do not need more complex configurations.
>
> Hmmm, you mean just one runtime properties and all the rest placed in
> the configuration section?
>
Not really. I think that match are simple enought to have just one
configuration paramenter and so we can just place it after an "="
avoiding a complete configuration structure.
ans so :
<match id="CheckHeader=sender:[EMAIL PROTECTED]"/>
where CheckHeader is the class name instead of
<match id="checkHeader"/>
...
<match id="checkHeader" class="CheckHeader">
<name>sender</name>
<value>[EMAIL PROTECTED]</value>
</match>
I just think the first one is less verbose and it's enought to cover all
needs... but I'm not sure about it... maybe a AntiSpam cmatch needs much
more configuration than a single line.
>
> I do, on the other side, redundancy allows you to change one portion
> without affecting all the rest....
>
> I'm worried about manageability costs here: how hard would be to
> "restructure" or "rebalance" the tree, compared to add other pipelines?
>
> I don't know, this is pure speculation since no server is using such
> configurability anyway...
>
> My early experience shows that multiple (even if overlapping) pipelines
> are very easy to manage for Cocoon2 and people really appreaciate
> them.... but we never took the tree path.
>
> But probably "symmetrical reasoning" could be misleading given the
> differences in serving capabilities and required functionality.
>
I can tell from my experience: "the less lines the less errors" but of
course this appiles to me only. :-)
>
> Please, allow me to summarize the intents for everybody that is
> involved:
>
> [....]
>
> To me, it seems this proposal would allow everybody to be happy, what do
> you think?
>
Actually my point was a step before. IMHO mail administrator needs may
change drastically form server to server and since I don't really have a
clean picture af what can we expect from mail application I was
wandering: why not provide the ability to chose which kind of
processing pipe and related configuration style to use?
Basically from the spool you get one mail and you call someone to handle
it. Just one mailet can do the job and from James point of view it is
irrelevant how it is handled. So I can write a mailet that calls other
mailet depending on its configuration. This "root mailet" is what I
called processing pipe.
So I can plug a root mailet that reads tree like configurations and
makes specified mailets work this way or I can plug a different root
mailet that reads linear confs and makes mailets work that way. We ca
write two or three differen root mailet to cover every differen need,
from the isp with 10000 users with no specific need to the ecommerce
mail application provider with fewer users but a bunch of intricated
mailet structure.
In other way i think we should take the processing pipe logic out of
JamesSpoolManager.java and make it pluggable.
If you look at ProcessingPipe.java and Pipe.java (horrible names but I
couln't find any beter) you'll see that those are mailet handling other
mailet based on their configurations.
Comments?
Fede
> --
> Stefano Mazzocchi One must still have chaos in oneself to be
> able to give birth to a dancing star.
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/>
Problems?: [EMAIL PROTECTED]
