cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <>
Subject RE: [RT] A deprecated module
Date Wed, 04 Dec 2002 11:10:54 GMT

Nicola Ken Barozzi wrote:
> Carsten Ziegeler wrote:
> > Hi,
> > 
> > it just came across my mind to create a "deprecated" block/module
> > which contains all deprecated classes and interfaces. This would
> > clean our core but we would still have compatibility when the
> > block is used.
> > 
> > Does this make sense? What do you think?
> I think that the idea is excellent, but I wouldn't make it a block.
> Blocks will be pluggable components, ut what you envision may need the 
> classes at startup.
> I would propose that we mimic the blocks build system for a section that 
> contains Cocoon "parts" that can be used on startup, but can be taken 
> out of the core.
> I sent a mail some time ago about this, to create "modules" alongside 
> blocks, but then I married, didn't follow it, and didn't even see if it 
> had arrived ;-)
> In this way the core can be smaller still, and we can keep additional 
> functionality that is not part of the blocks concept separate. This 
> could also help in making Cocoon profiles for smaller devices or such.
> We would still have to decide the name though, is "modules" ok? Dunno.
Ah, now here we have the old modules vs. blocks discussion... :)
I still think that the current "blocks" we have in the cvs head are the
modules - and when we introduced them, I proposed to call them modules
first. Ok, but that's the past - let's be constructive.

I'm fine with the name modules and this separation. But then we should
perhaps rename the modules.xml to something else.


Carsten Ziegeler 
Open Source Group, S&N AG

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

View raw message