cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: [SUMMARY] input module chaining
Date Thu, 10 Oct 2002 09:26:55 GMT

Carsten Ziegeler wrote:
> Piroumian Konstantin wrote:
> 
>>>I think we (= Cocoon community) should clarify our opinion 
>>>about this first. This includes:
>>>- Do we have a simple Sitemap InputModule Component?
>>
>>We have simple InputModule Component and it's not a sitemap component at
>>all.
>>
>>
>>>- Are the current InputModule and OutputModules of a more 
>>>general approach
>>>  and do we want to donate it?
>>
>>Not sure here. The most applicable place for InputModules, IMO, are the
>>sitemap substitution variables. I've never used OutputModules, so 
>>can't say
>>anything about them.
>>
>>
>>>If we agree on this, then the next step would be to involve 
>>>the avalon community.
>>
>>I feel that we are again going to stuck. Can't we move on with them in
>>Cocoon and then if we see that modules are general enough to be used in
>>Avalon then we'll move them there?
>>
> 
> Ok, perhaps I didn't make myself so clear: My proposal is to define
> two InputModules:
> a) One simple sitemap InputModule as discussed in the last days
> b) The general approach already implemented. And this general
>    approach should not reside in Cocoon.

You and I are also Avalon committers but most of the Cocoon devs aren't.

The inputmodule community is here, don't break it just for the sake of 
conceptual purity. Let's continue here and eventually move them later to 
Avalon (if ever) when they are stable.

Moving components to Avalon CVS has already upset some on different 
projects, because it brings to lack of control. James committers are 
very frequently upset by the fact that they have to rely on components 
they have difficulty in controlling.

Avalon Components IMNSHO should reside in a sort-of Avalon-Commons 
shared CVS; also some Turbine folks seemed interested, and we may have 
it someday, but for now moving all Avalon components in the "Avalon 
safe" is not the way to go.

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message