-----Mensagem original----- De: Ralph Goers [mailto:[EMAIL PROTECTED]
> It is interesting to see the discussion on "Avalon". Avalon itself is > actually pretty small. However, when you add on Excalibur it becomes much > larger. I'm never clear when the discussion is about Avalon whether the > discussion is really about Avalon or Avalon + Excalibur. I think you are misunderstanding things.. Exacalibur is a set of reusable components. Yup, there is also an ECM fella that shares the name and is used by cocoon. But this doesn't make avalon larger. > Not that I'm against switching to another container, its just that I thought > Avalon was originally born from Cocoon in the first place. What is ironic > is things like the Source Resolver that used to be cocoon classes are now > Excalibur classes. Just for creating a library - or something similar - of reusable components. > I think a major problem is that the "container" (i.e. Excalibur) has just > gotten way too large. IMO it should be about managing the lifecycle and > pooling of components and nothing else. AFAIK ECM does exactly that and nothing else.. > Personally, I think the path that has been proposed is probably as good as > any other. Sure, it will have negative consequences, but so do all the other > options. However, I would make sure that other available frameworks cannot > be leveraged to some degree before doing the whole thing from scratch, but > that is just me. +1 We have a different container implementation in every single corner nowadays. I understand why is too risk for Cocoon to choose one of them - social implications at most - and I agree. Under this conditions I think Cocoon should have its own container implementation. -- hammett
