Leo Simons wrote:
Component writers which follow this rule when writing Avalon components will create a component that is impossible to use in excalibur, cocoon, james, loom, plexus, phoenix, and other software projects that aim to support Avalon components. As such, it is highly backwards-incompatible and "sideways-incompatible". It effectively destroys the common denominator between these projects for no good reason.
This is the underlying problem to lack of specification, which I have been jumping up and down over before, but haven't had time to really dig into.
If you have two systems in a single contract, you can't modify the contract (other than clarify ambiguities), since any change can be utilized by one side, without the other, i.e. creating an incompatibility.
If I write a Servlet against ver 2.3 of the spec, it won't run in Servelet 2.2 containers. Simple as that, and this is no different.
Now, question could be raised whether it warrants a larger version bump than given, but I kindly refer to the Servlet example. (Closer to home is what is happening in Excalibur TLP, many things are axed breaking compatibility for 'satellite' projects, for the benefit of a better future.(I haven't seen Excalibur Chair vetoed any of those changes.))
So, containers that doesn't evolve will remain a AF4.1 container, not an Avalon 5 container. Where is the problem with that?
Furthermore, it requires a very high degree of self-discipline to be able to write cross-container compatible components, mostly due to deployment semantics, but also for lookup() semantics. I.e. if you are driving your components against a cross-container development, you know the limitations of the targetted containers, and can choose the 'good old way' of Null constructors (which the 'pico camp' is arguing so strongly against funny enough).
Regarding the 'discuss the changes' more thoroughly;
We all know where that will end up. And forwarding the overall product is more important than left/right/forward/up/down-compatibility concerns, since it will not be possible to maintain for both sides of the specification contract. As long as the old components run in old and new containers, I don't have a problem with lazy consensus and progress prevailing over endless discussions over a method name. We have been there, done that and won't go there again. Sorry, it kills the interest in participating...
Regarding 'de-emphasizing common ground';
We are not de-emphasizing common ground, but in fact the opposite. WE (Avalon-proponents, opposed to pico-proponents with Avalon legacy) are recognizing that the 'common ground' is too small for any inter-operability at a 'new scale'. We are working to extend the common ground, which by definition makes the previous common ground area RELATIVELY smaller.
Cheers Niclas
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
