avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noel J. Bergman" <n...@devtech.com>
Subject RE: On Multiple Containers
Date Fri, 22 Nov 2002 19:00:16 GMT
> I actually think it is closer now than at any time before because we have
> found which approaches don't work

Good, then you should be willing to help avoid the past errors --
constructively.  But it is not constructive to say "that doesn't work"
without offering a constructive suggestion about what might work.  It might
be hard, but it is the right thing to try.

> Combine that with compiled interceptor chains and
> we have a viable container IMO that satisfies all
> our needs.

Now you just need to explain that to the class ( :-) ), and illustrate the
role it plays in addresses the disparate needs, and why everyone should
follow your line of reasoning.  It provides a realm of constructive debate.

> However - in no way shape or form do I intend to bet the farm on my
belief.
> Incremental controlled changes are much better in this particular
situation
> because the changes do not require a revolution - just evolution.

There have working containers.  I don't believe that anyone is trashing
them.  The point is to build a working community with a goal, and to start
the journey to get there.  And I do not believe that the journey takes only
a few steps.  But it must be a journey taken together as a group, not
multiple journeys taken by individuals.  If you don't understand anything
else I am saying, please understand that point.

> an Avalon container host Avalon components in an environment and provides
> resources to such components. Thats about where the absolute commonalities
> end.

That is the LCD.  We can do better.  You've just finished saying as much.
Focus on what CAN be done.  :-)

1. information about component type (aka ComponentInfo)
2. information about how to a assemble a component instance (aka
ComponentMetaData)
3. information about runtime state of component (or components in case of
pooled components) (aka ComponentEntry)

> Now [component info] can be cross container relatively easy.
> [Component assembly] is likely to be about 70% portable
> between containers
> [component runtime state] will most likely be completely
> container dependent.

You've just pointed out more code that you think can be shared, and a few
where you think there will be differences.  These points can be discussed,
and acted upon as the community agrees.  And the third point can be
discussed separately to see if there really might be more commonality than
you currently perceive.  But first I would start with the low-hanging fruit,
and get to the harder ones as more and more code merges.

With respect to the assembly issues, perhaps the 30% that isn't shared can
be abstracted behind pluggable interfaces?  I don't know.  Just tossing out
a thought that perhaps the differing implementations still play the same
basic role.

> The above [ -- including implementation ideas I didn't clip -- are]
> the basic concepts required to achieve [any degree of commonality]
> between containers.  However I believe pushing any concepts now or
> trying to do a revolution is a bad idea.  I think we need more in
> the way of evolution.

The journey is performed in steps.  Containers don't fall off of cliffs.
But you've got to start, and then do it as a group.  For each step there
must be a community vision and agreement.  Perhaps the initial steps will be
slower, but as the community gets stronger, the next steps will be faster
and bigger.

> After that stage I think we just let time & darwin do it's job.

Nope.  And you're really using the wrong example with me in the audience for
this debate.  I don't think that random mutation and natural selection is
the answer to this problem at all.  Ideas may compete within the community,
but the community must engage in consciously design.  If there is a communal
desire to test ideas, then those need to be isolated modularly from the rest
of the shared base, the same as any other area of differing functionality.
And in this area I do invoke the notion of evolution: there will likely be
different morphologies to satisfy different niches.  But a beak is still a
beak.

> it would be nice if functionality was gradually migrated from
> containers into toolkits (along with documentation and unit
> tests) - much like Phoenix is doing. That way each bit of
> functionality can be reused by other containers where they want.

Well, that's a goal.  And how's about ONE toolkit?  :-)

	--- Noel


--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message