Peter Donald wrote:
Yes, you are right. But this is exactly the point: if we have one container (or a chain of containers extending one another), then we force the community to agree on how to define components.On Fri, 22 Nov 2002 18:50, Stefano Mazzocchi wrote:And the only way I see to do something about it is to have people talk about disagreements that they couldn't solve and containers are the most important point of friction around here so I started from there.
Actually containers have never really been a cause of friction. Most of us who work on containers have worked on multiple containers (either in Avalon or outside). The friction instead arises from definition of components and associated semantics. So this has less to do with "what container will I run?" and more to do with "How do I define components?" If you look back at the flames they are almost all about this.
Even back when you were involved that was the primary source of friction.
Yep
Should we have marker interfaces? Should we have ComponentSelectors? Should we have release on CM? Should we use info model X or Y? etc.Yes, exactly.
Here is what I would like to see (this is just my personal vision):
1) Avalon agrees on having one modular container or several containers that extend one another
2) in order to do this, the definition of components, their lifecycles and the rest of the COP-associated semantics is discussed based on *functional requirements* and not architectural tastes. Consensus is reached and results are specified and futher controlled by this community.
Results:
1) there is *one* framework and *one* definition of components
2) components interoperate between container implementations
3) behavior is inherited between extending containers so that maintenance and back compatibility is easier to control
It is obvious that each one of us has to accept some compromises in what he/she believes it's a perfect solution, and this is why I would like to start from the functional requirements rather than from the architectural differences that are already in place.
Personally, and this is my first step toward a compromise, I'm willing to accept back-incompatible changes to the way components are defined, if this makes sense from a functional point of view and if this helps making the avalon community stronger, more unified and healthier.
--
Stefano Mazzocchi <[EMAIL PROTECTED]>
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
