You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by "Stepanossov, Kirill" <ks...@lehman.com> on 2002/11/26 16:18:49 UTC
RE: [VOTE] avalon's future - take 2 (was [vote] avalon's future
)
Committers, if this accepted, could you still leave different "toolkits" for
building customized containers available ? The point is that no matter how
many different containers Avalon would offer, there be always a project for
which no suitable container would be found. Either they may offer too much
or too little. Personally, would prefer to have several "toolkits" for
building the majority of possible containers + a few containers as examples
of constructing containers from those "toolkits"...
I remember that when first time I wrapped my business components into
Avalon lifecycle interfaces I wanted to see them running ASAP, but tweety
did not provide the ordering of components initialization and others
containers seemed too complex for start, so I had to come with a tweety
modification by myself ...
Stefano Mazzocchi wrote:
[...]
>
> I would like to see three containers, each one of them extending the one
> underneath.
>
> - basic container
> - embeddable container
> - standalone container
>
> the first should fit with the framework to provide a reasonable
> lightweight system for simple avalon uses (no fancy stuff like pooling
> or anything).
>
> users of this basic implementation should be the people willing to learn
> avalon or use it in their own stuff but without fancy features.
>
> the second should be the juicy implementation of the avalon framework,
> but should remain embeddable. Since it extends the basic framework,
> every change applied to the framework reflects up.
>
> users of this implementation will be projects that use avalon
> extensively but internally (as an embedded COP system)
>
> the third should be the biggest implementation, extending the second and
> providing standalone running capabilities.
>
> users of this implementation will be projects that are run directly by
> avalon with full IoC.
>
> Tweety can be the first
> A mix of Merlin and Fortress can be the second
> Phoenix can be the third
>
> Note that this is more a community vision than a technical vision. All
> technical decisions will be made *after* this vote is taken.
>
> So, do you like this vision? would you like it to happen?
From the comments on this and based on the discussions of the past
months, I vote for this changed proposal:
**********************************************************************
This is more a community vision than a technical vision. All technical
decisions will be made *after* this vote is taken.
**********************************************************************
We shall have one only container, that can be built to match the
following profiles:
_micro_ container
_standard_ container
_enterprise_ container
The _micro_ implementation should fit with the framework to provide a
reasonable lightweight system for simple avalon uses (no fancy stuff
like pooling or anything)
The _standard_ implementation is the juicy implementation of the avalon
framework, and should remain embeddable. It's to be used as the normal
Avalon container. Users of this implementation will be projects that use
avalon extensively but internally (as an embedded COP system), like
Cocoon now.
The _enterprise_ third should be the biggest implementation, providing
standalone running capabilities. Users of this implementation will be
projects that are run directly by Avalon with full IoC.
Finally, there is a _tutorial_ container package (tweety&egg) that shows
the Avalon patterns by implementing them one by one.
-oOo-
ATM, the containers we have now map like this:
_tutorial_ - Egg+Tweety
_micro_ - Tweety
_standard_ - Merlin and Fortress
_enterprise_ - Phoenix
Egg is already tutorial only, and Tweety can be taken apart into simpler
parts and made into steps for comprehension.
Tweety as it stands can become the new "Default" stuff and supercede the
default implementations we have in framework.
Merlin and Fortress are in the same domain and can be reduced to a
single entity; they shall use the utilities created in the micro
version, as they do now with Excalibur utilities that will go in micro.
Phoenix is highly pluggable, and it seems to be best to keep it the same
from the outside: all the frontends remain the same and implement the
core using the standard container.
So, do you like this vision? would you like it to happen?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
------------------------------------------------------------------------------
This message is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] avalon's future - take 2 (was [vote] avalon's future )
Posted by Stephen McConnell <mc...@apache.org>.
Stefano Mazzocchi wrote:
> Why does everybody here think that COP and inheritance don't mix? Who
> said that?
>
> Example: Cocoon will need the embeddable container to implement cocoon
> blocks, but cocoon blocks will have features that are cocoon-specific,
> so Cocoon will have to "extend" this container to fit its needs.
>
> I know we'll have to do that.
Careful - you generalizing
;-)
OOP has its place - OOP is an approach that is perfectly OK at the fine
grain implementation level. COP suites more cause grained solutions.
Some people here (e.g. myself as an example) - think that COP and OOP
are complimentary.
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Peacemaker (was: RE: [VOTE] avalon's future - take 2)
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Mircea Toma [mailto:mirceatoma@apache.org]
>
> On Tuesday 26 November 2002 19:10, Stefano Mazzocchi wrote:
> > So, tell me, how would you suggest we move on?
>
> Agressive ... ? Remember you're the one trying to bring peace
> and order here!
Can you (+ everyone) please ***stop*** that? It seems as
every time Stefano throws in a rhetorical question, he gets a
oh-I-thought-*you*-were-the-one-wanting-peace.
It's not an argument, misleading as a statement, old as a joke
and not really getting anyone anywhere.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] avalon's future - take 2 (was [vote] avalon's future )
Posted by Mircea Toma <mi...@apache.org>.
On Tuesday 26 November 2002 19:10, Stefano Mazzocchi wrote:
> Mircea Toma wrote:
> >>Stepanossov, Kirill wrote:
> >>>Committers, if this accepted, could you still leave different "toolkits"
> >
> > for
> >
> >>>building customized containers available ?
> >>
> >>Why does everybody here think that COP and inheritance don't mix?
> >
> > They can mix but not very elegantly.
>
> that's not my perception.
>
> COP is promoting Composition as the
>
> > main design pattern isn't it?
>
> Sure, but nowhere is stated that these components can't follow OOP
> patterns themselves.
No, nowhere. Is just akward that's all. And that's not a good sign you know
that. As Stephen said OOP is complementary to COP (or orthogonal?!).
> >>Example: Cocoon will need the embeddable container to implement cocoon
> >>blocks, but cocoon blocks will have features that are cocoon-specific,
> >>so Cocoon will have to "extend" this container to fit its needs.
> >
> > If you think about blocks in the same way Cocoon extends ECM to provide
> > the specific functionality then you have a clear case were inheritance is
> > not doing a very good job.....
>
> Look: cocoon needs user-level application modules. think of them as COP
> for webapps. No web technology allows that.
Ok.
>
> Now, either we write our own container or we work with the avalon
> community to have the functionality we need in place. But *much* of this
> functional requirements will be cocoon-specific (like a sitemap exposure).
What's wrong in using Avalon as a container for components that put together
will create a container for the cocoon-specific components. I guess that's
why Avalon was called a "server of servers".
> So, tell me, how would you suggest we move on?
Agressive ... ? Remember you're the one trying to bring peace and order here!
> write *yet another
> container* because the COP patterns suggest that and we don't want to
> *pollute* other containers with cocoon-specific stuff?
No, I'm suggesting that any feature that is not general enough to go into
Avalon is to be modeled as a component/service deployed on top of it. Even if
the service would be another container.
> why can't we take what's there and *extend* it for our needs? what's
> wrong with that?
Tell me, in Java every time you need new functionality you go to Sun and ask
for another compiler reserved word or you'll create a object/method that will
give you what you need?
Mircea
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] avalon's future - take 2 (was [vote] avalon's future )
Posted by Stephen McConnell <mc...@apache.org>.
Stefano Mazzocchi wrote:
> Mircea Toma wrote:
>
>>> Stepanossov, Kirill wrote:
>>>
>>>> Committers, if this accepted, could you still leave different
>>>> "toolkits"
>>>
>>>
>> for
>>
>>>> building customized containers available ?
>>>
>>>
>>> Why does everybody here think that COP and inheritance don't mix?
>>
>>
>>
>> They can mix but not very elegantly.
>
>
> that's not my perception.
>
> COP is promoting Composition as the
>
>> main design pattern isn't it?
>
>
> Sure, but nowhere is stated that these components can't follow OOP
> patterns themselves.
>
>>> Example: Cocoon will need the embeddable container to implement cocoon
>>> blocks, but cocoon blocks will have features that are cocoon-specific,
>>> so Cocoon will have to "extend" this container to fit its needs.
>>
>>
>>
>> If you think about blocks in the same way Cocoon extends ECM to
>> provide the
>> specific functionality then you have a clear case were inheritance is
>> not
>> doing a very good job.....
>
>
> Look: cocoon needs user-level application modules. think of them as
> COP for webapps. No web technology allows that.
>
> Now, either we write our own container or we work with the avalon
> community to have the functionality we need in place. But *much* of
> this functional requirements will be cocoon-specific (like a sitemap
> exposure).
>
> So, tell me, how would you suggest we move on? write *yet another
> container* because the COP patterns suggest that and we don't want to
> *pollute* other containers with cocoon-specific stuff?
>
> why can't we take what's there and *extend* it for our needs? what's
> wrong with that?
You can today - use Merlin.
You will tommorow - use a common containment framework as the abstract base.
Life should be simple - MyMoreImportantThing extends
ReallyCoolCommunityThing + 3 lines of code.
Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] avalon's future - take 2 (was [vote] avalon's future )
Posted by Stefano Mazzocchi <st...@apache.org>.
Mircea Toma wrote:
>>Stepanossov, Kirill wrote:
>>
>>>Committers, if this accepted, could you still leave different "toolkits"
>>
> for
>
>>>building customized containers available ?
>>
>>Why does everybody here think that COP and inheritance don't mix?
>
>
> They can mix but not very elegantly.
that's not my perception.
COP is promoting Composition as the
> main design pattern isn't it?
Sure, but nowhere is stated that these components can't follow OOP
patterns themselves.
>>Example: Cocoon will need the embeddable container to implement cocoon
>>blocks, but cocoon blocks will have features that are cocoon-specific,
>>so Cocoon will have to "extend" this container to fit its needs.
>
>
> If you think about blocks in the same way Cocoon extends ECM to provide the
> specific functionality then you have a clear case were inheritance is not
> doing a very good job.....
Look: cocoon needs user-level application modules. think of them as COP
for webapps. No web technology allows that.
Now, either we write our own container or we work with the avalon
community to have the functionality we need in place. But *much* of this
functional requirements will be cocoon-specific (like a sitemap exposure).
So, tell me, how would you suggest we move on? write *yet another
container* because the COP patterns suggest that and we don't want to
*pollute* other containers with cocoon-specific stuff?
why can't we take what's there and *extend* it for our needs? what's
wrong with that?
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] avalon's future - take 2 (was [vote] avalon's future )
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Mircea Toma [mailto:mirceatoma@apache.org]
>
> > Stepanossov, Kirill wrote:
> > > Committers, if this accepted, could you still leave
> different "toolkits"
> for
> > > building customized containers available ?
> >
> > Why does everybody here think that COP and inheritance don't mix?
>
> They can mix but not very elegantly. COP is promoting
> Composition as the
> main design pattern isn't it?
No. Components are building blocks of a system that allows you
to design in a loosely coupled, yet intelligent way. Components
are often "services" (components that perform a specific task).
Architectures like EJBs, and in particular the Entity Beans have
done damage to the credibility and design of components. In
Entity Beans, composition is the main design patterns. However,
the world is not Entity Beans.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] avalon's future - take 2 (was [vote] avalon's future )
Posted by Mircea Toma <mi...@apache.org>.
> Stepanossov, Kirill wrote:
> > Committers, if this accepted, could you still leave different "toolkits"
for
> > building customized containers available ?
>
> Why does everybody here think that COP and inheritance don't mix?
They can mix but not very elegantly. COP is promoting Composition as the
main design pattern isn't it?
> Who
> said that?
>
> Example: Cocoon will need the embeddable container to implement cocoon
> blocks, but cocoon blocks will have features that are cocoon-specific,
> so Cocoon will have to "extend" this container to fit its needs.
If you think about blocks in the same way Cocoon extends ECM to provide the
specific functionality then you have a clear case were inheritance is not
doing a very good job.....
Mircea
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] avalon's future - take 2 (was [vote] avalon's future )
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
>
> Stepanossov, Kirill wrote:
> > Committers, if this accepted, could you still leave
> different "toolkits" for
> > building customized containers available ?
>
> Why does everybody here think that COP and inheritance don't mix? Who
> said that?
Noone. COP is an extension of OOP in many respects. All it does
is simplify the problem domain by providing a stricter set of solutions.
You can implement components using inheritance, there is no problem
with that. In the container's view, they are completely different
components. It's no biggy, its just that sometimes we see through
the containers eyes sometimes.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] avalon's future - take 2 (was [vote] avalon's future )
Posted by Stefano Mazzocchi <st...@apache.org>.
Berin Loritsch wrote:
>> + Thus, the less design we have to do, the less initial conflicts.
>
> And the longer it takes to learn to work together. Let's see
> if we can go from Apache's embarrassment to their poster-child.
Amen!
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] avalon's future - take 2 (was [vote] avalon's future )
Posted by Berin Loritsch <bl...@citi-us.com>.
> From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
>
> > From: Stefano Mazzocchi [mailto:stefano@apache.org]
> >
> > The history of this project showed pretty evidently how
> COP-patterns
> > applied to community building creates fragmentation and
> isolation and
> > friction. Toolkits might be technically easier to use to
> achieve user
> > goals but are bad for the evolution of a coherent and focused
> > development community.
>
> OK, if I follow your reasoning correctly:
>
> + Inheritance requires design.
>
> + Composition requires less design.
I won't agree with the second statement. Everything requires
design. Composition and Inheritance both require the same
amount of design. In fact, finding the best balance between
the two is the key to *good* design.
Start with something concrete, and if it can be moved out and
maintained separately as a tool, then you do it. Don't work
the other way around.
> + Design means that we have to come together on some issues.
Absolutely. Amen.
> + Thus, the less design we have to do, the less initial conflicts.
And the longer it takes to learn to work together. Let's see
if we can go from Apache's embarrassment to their poster-child.
> + So that's why a "several toolkit" approach, where everyone
> just shoots off their own little corner of Avalon and builds
> stuff is so tempting.
And not helpful. Esp. when we have more than one toolkit that
performs the same basic function.
> + But with everyone in their own corner, we're not really
> getting a community.
Right. At this point community is paramount. You might be amazed
at how quickly the product comes together after the community is
built.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] avalon's future - take 2 (was [vote] avalon's future )
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
>
> The history of this project showed pretty evidently how COP-patterns
> applied to community building creates fragmentation and isolation and
> friction. Toolkits might be technically easier to use to achieve user
> goals but are bad for the evolution of a coherent and focused
> development community.
OK, if I follow your reasoning correctly:
+ Inheritance requires design.
+ Composition requires less design.
+ Design means that we have to come together on some issues.
+ Thus, the less design we have to do, the less initial conflicts.
+ So that's why a "several toolkit" approach, where everyone
just shoots off their own little corner of Avalon and builds
stuff is so tempting.
+ But with everyone in their own corner, we're not really
getting a community.
/LS
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] avalon's future - take 2 (was [vote] avalon's future )
Posted by Stefano Mazzocchi <st...@apache.org>.
Stepanossov, Kirill wrote:
> Committers, if this accepted, could you still leave different "toolkits" for
> building customized containers available ?
Why does everybody here think that COP and inheritance don't mix? Who
said that?
Example: Cocoon will need the embeddable container to implement cocoon
blocks, but cocoon blocks will have features that are cocoon-specific,
so Cocoon will have to "extend" this container to fit its needs.
I know we'll have to do that.
> The point is that no matter how
> many different containers Avalon would offer, there be always a project for
> which no suitable container would be found.
Gosh, of course! this is why this is a 'framework'. we are not locking
people in, we are just deciding what functionalities to implement in
each profile but there we are not planning to make all method calls
*final* for &deity;'s sake!
> Either they may offer too much
> or too little. Personally, would prefer to have several "toolkits" for
> building the majority of possible containers + a few containers as examples
> of constructing containers from those "toolkits"...
The history of this project showed pretty evidently how COP-patterns
applied to community building creates fragmentation and isolation and
friction. Toolkits might be technically easier to use to achieve user
goals but are bad for the evolution of a coherent and focused
development community.
Which one do you prefer: a technical solution that works now but might
leave you alone in the future because the maintainer decided to do
something else, of a technical solution that imposes some work on you
but will be maintained for that point on by an active community?
It's your ass you're betting on Avalon, do you have the energy to
maintain a one-man-show toolkit if the original showman leaves or is
kicked out?
Wouldn't you be more confortable on a solution maintained by several
different individuals? wouldn't it be harder to see the development
effort disappear?
It's yous ass, dude, think about it.
--
Stefano Mazzocchi <st...@apache.org>
--------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] avalon's future - take 2 (was [vote] avalon's future )
Posted by Stephen McConnell <mc...@apache.org>.
Stepanossov, Kirill wrote:
>Committers, if this accepted, could you still leave different "toolkits" for
>building customized containers available ? The point is that no matter how
>many different containers Avalon would offer, there be always a project for
>which no suitable container would be found. Either they may offer too much
>or too little. Personally, would prefer to have several "toolkits" for
>building the majority of possible containers + a few containers as examples
>of constructing containers from those "toolkits"...
> I remember that when first time I wrapped my business components into
>Avalon lifecycle interfaces I wanted to see them running ASAP, but tweety
>did not provide the ordering of components initialization and others
>containers seemed too complex for start, so I had to come with a tweety
>modification by myself ...
>
Kirill:
This is very much the structure I would like to see - a comon framework
(tookit), and above that a series of containers based on profiles that
address different busienss/development concerns/requirements.
Cheers, Steve.
>
>Stefano Mazzocchi wrote:
>[...]
>
>
>>I would like to see three containers, each one of them extending the one
>>underneath.
>>
>> - basic container
>> - embeddable container
>> - standalone container
>>
>>the first should fit with the framework to provide a reasonable
>>lightweight system for simple avalon uses (no fancy stuff like pooling
>>or anything).
>>
>>users of this basic implementation should be the people willing to learn
>>avalon or use it in their own stuff but without fancy features.
>>
>>the second should be the juicy implementation of the avalon framework,
>>but should remain embeddable. Since it extends the basic framework,
>>every change applied to the framework reflects up.
>>
>>users of this implementation will be projects that use avalon
>>extensively but internally (as an embedded COP system)
>>
>>the third should be the biggest implementation, extending the second and
>>providing standalone running capabilities.
>>
>>users of this implementation will be projects that are run directly by
>>avalon with full IoC.
>>
>>Tweety can be the first
>>A mix of Merlin and Fortress can be the second
>>Phoenix can be the third
>>
>>Note that this is more a community vision than a technical vision. All
>>technical decisions will be made *after* this vote is taken.
>>
>>So, do you like this vision? would you like it to happen?
>>
>>
>
> From the comments on this and based on the discussions of the past
>months, I vote for this changed proposal:
>
>**********************************************************************
>This is more a community vision than a technical vision. All technical
>decisions will be made *after* this vote is taken.
>**********************************************************************
>
>We shall have one only container, that can be built to match the
>following profiles:
>
> _micro_ container
> _standard_ container
> _enterprise_ container
>
>
>The _micro_ implementation should fit with the framework to provide a
>reasonable lightweight system for simple avalon uses (no fancy stuff
>like pooling or anything)
>
>The _standard_ implementation is the juicy implementation of the avalon
>framework, and should remain embeddable. It's to be used as the normal
>Avalon container. Users of this implementation will be projects that use
>avalon extensively but internally (as an embedded COP system), like
>Cocoon now.
>
>The _enterprise_ third should be the biggest implementation, providing
>standalone running capabilities. Users of this implementation will be
>projects that are run directly by Avalon with full IoC.
>
>
>Finally, there is a _tutorial_ container package (tweety&egg) that shows
>the Avalon patterns by implementing them one by one.
>
> -oOo-
>
>ATM, the containers we have now map like this:
>
> _tutorial_ - Egg+Tweety
> _micro_ - Tweety
> _standard_ - Merlin and Fortress
> _enterprise_ - Phoenix
>
>
>Egg is already tutorial only, and Tweety can be taken apart into simpler
>parts and made into steps for comprehension.
>
>Tweety as it stands can become the new "Default" stuff and supercede the
>default implementations we have in framework.
>
>Merlin and Fortress are in the same domain and can be reduced to a
>single entity; they shall use the utilities created in the micro
>version, as they do now with Excalibur utilities that will go in micro.
>
>Phoenix is highly pluggable, and it seems to be best to keep it the same
>from the outside: all the frontends remain the same and implement the
>core using the standard container.
>
>
>So, do you like this vision? would you like it to happen?
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>