Federico Barbieri wrote:
>
> 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.
Yes, that was my point.
-1 on forcing just one configuration.
> >
> > 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. :-)
While this is generally true, verbosity somehow increases readability
and reduces management costs, expecially when you work with others that
don't have the same set of skills that you have.
> >
> > 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?
I disagree: mail administrator needs may change drastically, but mail
functionalities are not that many. By having pluggable components and a
way to connect them together, you are covering 99% of your issues.
> 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.
True, just like Cocoon can be seen as a servlet engine extention for
dealing with XML content.
On the other hand, it should be JAMES to create the pipelines, not a
mailet.
> In other way i think we should take the processing pipe logic out of
> JamesSpoolManager.java and make it pluggable.
Hmmm, while this smells like flexibility syndrome, I wonder if project
like Cocoon could take advantage of this architecture.... I honestly
don't know, but I would say, we should aim for something like this for a
future version and concentrate on having something working soon.
> 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.
hmmmm
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/>
Problems?: [EMAIL PROTECTED]
