avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paulo Gaspar" <paulo.gas...@krankikom.de>
Subject RE: Fresh Perspective
Date Wed, 19 Jun 2002 20:35:14 GMT


I must say I am enjoying a lot the discussion these last days, even
when I am keeping my big mouth shut. 

And keeping my mouth shut is so easy when someone else asks the 
questions for me. =;o) With many of the ideas of my work being based
on Cocoon, Berin, Stefano and Ken end up having the same doubts and
posting better questions than I would be able to.


Leo's post is over a subject that interests me a lot. 

However, I am afraid that a very flexible general selection mechanism
would become so complex that it would be easier (cheaper) to use Java
or script to define complex selections than to learn/manage such 

It is a bit like some "declarative" (often XML-ized) syntaxes that 
turn into mini-programming languages that one has to learn in addition
to (in our case) Java, don't have its power and often need much more 
coding to get to the same result. (Struts, XSLT and even some Cocoon
stuff made me feel this way too.)

I wonder if it wouldn't be wise to keep such a mechanism focused on
solving the simpler cases and just leave the door open to 
"programmatically" solve the more complex ones.

BUT please do not misinterpret my words: I like very much the line of
ideas that Leo is exposing here. What I am trying is to keep this line
from becoming over ambitious.

Have fun,
Paulo Gaspar

> -----Original Message-----
> From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
> Sent: Wednesday, June 19, 2002 9:26 PM
> I'd like to be able to plug in selection policies in the container,
> independent of what it is they are selecting between - mail servers,
> signature taglines, whatever. Maybe I want to post-process every mail
> sent to @apache.org in some special way. If S was independent of
> the type of service it selected on, I could use S for that as well.
> But if we tie S to become a "MailServerManager", then it is only 
> that...
> Do you have any idea of how to solve this use case in your framework?
> For the general case, what I want is this:
>   + A should not have to care that there is a selection policy
>     in place.
>   + Selection policies should be able to be linked (first apply rule A,
>     the rule B, and so on).
>   + If A supplies a hint for the selection policy, it should work
>     even if there is no policy in place.
>   + Policies should be independent of the type of service they apply to.
>     For example, a TimeOfDayPolicy should be able to select among 
>     mail servers or SAX transformers equally well.
> /LS

To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message