Stephen, Dude, I was not trying to be offensive... Your proposal was not half-baked, it was well thought out.
- Paul >Paul: > >I guess I'm looking at this from a completely different point >of view. After coming up with my half-backed proposal for >changes to ComponentManager (I shouldn't make proposals after >being awake that long), I was rightfully shot down on the issue >of backwards compatibility. Now its clear that the >compatibility question is technical debatable - after all, >if anyone really using a returned value of component as Component? >Bottom line - its contractual - and you don't break contracts >(forget about the technical issues .. its marketing principal >we need to worry about). So option (1) isn't an option. We >have option (2) and option (3). Before Pete sent his suggestion >I had been playing around with variants - one approach was to >come up with a specialisation of ComponentManager but that just >turned into Minestrone soup (specialising a class to add what >in principal should be super-type behaviour). I tried a couple >of variants of this but constantly ran foul of the fact that >DefaultComponentManager has a parent ComponentManager which >implies lots if [if instanceof Component do X else do Y] stuff. >My conclusion from that was to drop the idea of Band-Aid >treatment (a) because it just didn't hang together, and (b) >Avalon is fundamentally very clean in the Band-Aid principal was >ranking very high on the "suck" scale. Next step was to address >extension (ComponentManager2 or a other name in the same package) >or a new package. I tried coming up with new package >names but frankly could not think of anything with the equivalent >elegance of the current framework packages - furthermore, I really >struggle trying to come up with some more meaningful class names >assuming continuation under the component package. Put it down >to insufficient IQ - I didn't arrive at anything interesting and >that bugged me most on marketing grounds. > >Five minutes later Pete posted his suggestions, one of which I >jumped on immediately - the framework/service package (with >adjustment to correct the spelling to Serviceable :-)). > >Here is why I jumped ... > > (1) because it grammatically made perfect sense in the context > of the overall framework > (2) because I can market those terms without compromising > anything on the component model - in fact enhancing it > (see point 3) > (3) because I can leverage the fact that the Avalon > component model now encompasses legacy applications > (evidence of which is already implemented and tested) > >And most importantly for me ... > > (4) because I'm busy recruiting new Avalon advocates from > a legacy (CORBA) community (that are reading these > messages) and I need a clean story backed by a relevant > set of interfaces and implementations (which we now have > pending general agreement - example org.apache.orb.ORB > can now be supplied by a manager to the components it > manages while maintaining 100% CORBA spec compliance and > incorporating the Avalon component model for logging, > configuration, and contextualization). > >Summary .. this isn't ComponentManager2! >The new package quite elegantly reflects the computation interfaces >needed by a "component" in the declaration of the contracts >concerning the service provision and service disposal aspect. > >Cheers, Steve. > > >>-----Original Message----- >>From: Paul Hammant [mailto:[EMAIL PROTECTED]] >>Sent: Sunday, 10 February, 2002 17:18 >>To: Avalon Developers List >>Subject: Re: ComponentManager interface >> >> >>Stephen, >> >>I'm not so sure. We're trying to sell Component assembly, component >>orientated programming. With the proposal with Service as the >>replacement word, we've duplicated an entire package. I thought >>wholescale class cloning was no-no, even at tool level. >> >>We have three choices: >> >>1) Brave replacement of Component with Object return type on lookup(..). >> >> Pros: small change >> Cons: Not backwards compatible - lots of recompilation and possible >>casting needed for users of API >> >>2) Package clone (as per proposal booked in). >> >> Pros: backwards compatible. >> Cons: Overkill duplication, confusion. >> >>3) "2" suffixed interfaces >> >> Pros: new new package, backwards compatible. Smaller amount >>of changes. >> Cons: "ugly" digit suffix to interface names. >> >>I think (3) is a front runner. For (2) the "medicine is worse than the >>cure". (1) I would do for selfish reasons, but we'd upset various >>communities, possibly to the point of mutiny. >> >>However, I am not active in maint of framework. I will leave the >>decision to others, but state that my highest concern is a timeline. I >>will vote..... if (1) is vetoed I'll vote for (3) over (2) and I really >>believe that loading a gun and shooting a package to avoid a "2" suffix >>is over the top. >> >>- Paul >> >> >> >>>Paul: >>> >>>I don't agree with point concerning the absence of the >>>word "Component" - a component is an abstract thing - more >>>abstract than the computational descriptions we can put >>>into Java interfaces. In fact I think the absence of the >>>word component in the interface name clarifies (for me) the >>>function from a computational perspective as distinct from >>>the role of the interface in the overall component >>>abstraction. >>> >>>Its Sunday afternoon and there are just too many big word >>>in that paragraph - time I had another glass of wine! >>> >>>Cheers, Steve. >>> >>> >>>>-----Original Message----- >>>>From: Paul Hammant [mailto:[EMAIL PROTECTED]] >>>>Sent: Sunday, 10 February, 2002 14:25 >>>>To: Avalon Developers List >>>>Subject: Re: ComponentManager interface >>>> >>>> >>>>Peter, >>>> >>>>>>Composable2, ComponentManager2 ? >>>>>> >>>>>ewww - runaway, runaway ;) >>>>> >>>>I knew we we going round in circles dude.... You're the one pushing >>>>for 'Component becomes Object' (by implication) then backing away ;-) >>>> >>>>I don't like Stephens new ServiceXXXX stuff. I mean it is good. No it >>>>is perfect but for the absense of the word "Component". >>>> >>>>We are not without precident, all these from JDK1.4 : >>>> >>>> LayoutManager2 >>>> GlyphPainter2 >>>> Parser2 (Crimson) >>>> ElementNode2 >>>> NamespaceSupport2 >>>> >>>><fx> ducks from Peter's bullets </fx> >>>> >>>>Packages Evolve. Lets understand that. We have no versioning built >>>>into Java in the sense that two versions of the same API could >>>>interoperate in the same classloader/classpath. In ten years time we >>>>will have loads of dead packages (java.io is example) or loads of >>>>suffixed classes/interfaces. We could migrate all functionality >>>>immediately to the "2" versions and for the original versions have a >>>>hand crafted proxy that routes all calls through to the new one. >>>> >>>>It is one strategy that will be taken with AWT in the end I guess. >>>>Sun/Netacape built Swing on top of the AWT primatives, but kept AWTs >>>>own heavyweight comps. Sun could obsolete AWT and or have a near enough >>>>pure Java "AWT2" that AWT routes through to. In fact AWT could route >>>>through to Swing, more or less completely hiding the experience. In >>>>that version of the graphic toolkit all Swing would need from the >>>>iunderlying OS would be mouse, kbd and "rectangle reservation" graphics >>>>support. Swing could sit small OSs that have no advanced graphics API. >>>>Sigh... Java's original Component model ;-) >>>> >>>>- Paul >>>> >>>> >>>> >>>>-- >>>>To unsubscribe, e-mail: >>>> >>><mailto:[EMAIL PROTECTED]> >>>For additional commands, e-mail: >>> ><mailto:[EMAIL PROTECTED]> > >> >>-- >>To unsubscribe, e-mail: >> ><mailto:[EMAIL PROTECTED]> > >>For additional commands, e-mail: >> ><mailto:[EMAIL PROTECTED]> > >> >> > > > > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
