cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] Cocoonlet
Date Thu, 28 Apr 2005 13:46:17 GMT
Daniel Fagerstrom wrote:
> Vadim Gritsenko wrote:
>> Daniel Fagerstrom wrote:
>>> Our current (controversial ;) ) plan is to consider the sitemap and 
>>> the component aspect of the original block proposal as separate 
>>> concerns and (at least initially) solve them separately.
>> I propose less controversial plan.
>> As the first step, implement what you call "sitemap blocks", but call 
>> them simply "blocks". Own classloader, full classloading isolation, 
>> block protocol, exposing direct sitemap components: generators, 
>> transformers, serializers.
> I'm working on this part and I'm using the names that you all love ;)
>> As the second step, implement "components block" *on top of* "sitemap 
>> blocks". This introduces second classloader (one is public, to share 
>> component interfaces, and one is private, to contain components 
>> implementation and libraries), and logic for managing classloader 
>> trees. Still call it simply "block".
> I and Pier find this a mix of concern of reasons that you can find in 
> the archive. If we leave the mix of concern issue for the moment, your 
> plan involves *waiting* on the first step. That is for sure 
> uncontroversial, waiting on various component management refactorings 
> and so on, has been the main activity for most of us, most of the time 
> during the years that has past since Stefano's original proposal.
> Pier's proposal to actually start *doing* something about the "component 
> block" part of the equation right now, was way cooler, IMHO.

I believe it when I see it ;-)


View raw message