> Avalons framework (via configuration methods usually). I much prefer to fix
> "fix" avalon than to create a new project to replace Avalon.

I understand that. And I would agree - if library's goal would be only to
create components. 

But for few people it isn't - the components is just a mean to get to the
goals. 

Please understand I'm not arguing against "fixing" Avalon - and I'm sure
the library will give you an excelent oportunity to do that, and
componentize what is to be componentized.

Again: my goal is a project where existing projects can cooperate. And in
order to succeed we need a neutral project. Avalon is far from that. 

As you said earlier, components will be a by-product - as projects share
code and it is componentized, some of it will reach the "product" level we
want for components. 

All your arguments would be right if the library would try only to create
components, but this is not the case - and it took us a lot of effort to
find a common point and proposals where all our goals can be met. 

Costin







Reply via email to