On Sun, 2002-09-29 at 21:54, Leo Sutic wrote: > Leo Simons wrote: > > On Sat, 2002-09-28 at 15:26, Leo Sutic wrote: > > > + Avalon 4 contains the ComponentManager interface and thus > > > *all* component that claim to be Avalon 4 compatible MUST > > > support the Component interface. > > > > -1 on defining "avalon compatible component" this way. The whole point > > of service.* is that you can have "avalon compatible components" that do > > not implement Component! > > Basic problem I have with your reasoning: > > + It is not OK for a container to not support Composable (i.e. explode when > a composable component is loaded) and call itself 100% A4 compliant. This > is because we may be in a situation when we have a legacy component, and > we want that to work.
+1 > But this is only 1/2 of the contract: What are the rules for legacy > *containers*? > > In theory, if a container is 100% A4 compliant, it should remain so for all > future > versions of A4, in the same way that a component, once having achieved 100% > A4 status, > will remain so until A5. +1 > The Seviceable interface messes all that up. > > It is possible for a container to be Avalon 4.0 compliant, but not Avalon 4.1 > compliant. I disagree....I think you mess up a little of the container/component in the above? All 'compatible' *containers* must support components that implement the Composable interface. All containers from avalon framework 4.1 and onwards must support components that implement one or more of the Composable and Servicable interfaces. Not all avalon framework 4.1 and upwards compatible *components* have to implement the Component interface. I think we mean the same thing? > What to do: > > + All Excalibur components that were released prior to the introduction > of the > Serviceable interface have to implement the Component interface until A5. +1 > + Any new releases must clearly state that they are targeted at A4.1 unless > they implement Component, or if they use the service package. +1, though I still think they should mention they are targeted for 4.1 and higher even if they use the service package =) > + ECM remains JDK1.2 compatible. Look, the damn thing is legacy legacy > legacy. > It works fine, but I'd rather have it remain A4.0 instead of trying to > mutate > it to A4.1, unless that mutation can be done without JDK1.3. Branching is > another possiblity. Under JDK1.2, the lookup of a non-Component > implementing > component would throw a ComponentException, under 1.3 it would be solved > via the proxy generator. > > I think this solves Cocoon's problems. I hate branching....but....I'm okay with all alternatives wrt ECM for which broad consensus can be reached. > I also think we can be a bit more bold with A4.2, seeing as the damage is > already > done. Maybe we should take this chance to clean up, or even rename 4.2 to 5? I don't think that's a very good idea. There's no need to scare users.... > As for what the Serviceable interface is: I always considered it nothing > more than a > method for Avalon component to access non-Avalon components via a unified > lookup mechanism. hmm. The definition of 'avalon component' broadens because of service. You can also do all the cool dependency resolution, meta information, etc etc, for components not 'native' to avalon (ie CORBA components running direcly inside merlin). > Random thought: With the Proxy generator Berin put in the ECM, doesn't the > whole > need for Serviceable disappear? the thought crossed my mind too.... cheers, - other Leo -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
