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 Carsten Ziegeler Open Source Group, S&N AG --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
