cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: New "module" terminology: WAS: Extending the build system for modules
Date Thu, 22 Aug 2002 08:52:00 GMT

Giacomo Pati wrote:
> On Wed, 21 Aug 2002, Nicola Ken Barozzi wrote:
>>Giacomo Pati wrote:
>>>On Mon, 19 Aug 2002, Nicola Ken Barozzi wrote:
>>The contract/interface of a block is the union of all the descriptions
>>of what it exposes:
>> >>  1) Avalon component(s)
>>Not exposed, but Cocoon must be able to merge the supplied xconf with
>>the Cocoon one.
> Merging is one way, a hierarchy of Containers/CM/SM the other.

Yes. "Merge" conceptually.

Though maybe in the beginning we can make a quick working system out of 
simple merging.

I try to find the easiest solution ATM to get it working quick.

>>In the future we should separate them from cobs and have Cocoon work ala
>>Merlin via dependency descriptors.
> No, they are part of cobs.

IMHO no.
Avalon components can be used in other containers other than Cocoon, and 
so must be used as-is.

The cob in the future should define he dependency in the descriptor, but 
not /necessarily/ contain the Avalon component itself.
It will still be able to do contain them though, if they are tied to the 
Cocoon component ala couplet.

>>But if we buy in this too soon we would just loose time, without real gain.
> Can you explain?

If we try to build complete cob support from the start we will be doing 
a lot of work without knowing the impact, and use a lot of time and 
effort without knowing the outcome.

I prefer baby-steps if possible, so that we can quickly have a working 
system, gain feedback, make it better, etc.

>> >>  2) Cocoon component(s)
>>Cocoon components will be automatically available as declared in the
>>root sitemap.xconf.
> You think of a new config file (siteamp .xconf)? Cocoon components aren't
> defined in sitemap.xmap but in cocoon.xconf. You are confusing me.

   All pipelines consist at least of two components: ...
   <map:generators default="file">
     <map:generator label="content,data" .../>


>>Similar to what done with the Avalon ones.
>> >>  3) resources
>> >>  4) examples
>>Simply an URI set of values for the files and the list of the sitemap
>>snippets that can be called, with human-readable description of what
>>these do.
>>All this would make the system usable right away without big problems,
>>refactoring or design discussions.

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

To unsubscribe, e-mail:
For additional commands, email:

View raw message