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]>
