avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paulo Gaspar" <paulo.gas...@krankikom.de>
Subject RE: [desperate plea] RE: The need for 'hints'
Date Sat, 22 Jun 2002 18:17:01 GMT
Stefano,


All these ideas sound great and clear, but if you want to make such
concepts last we can not simply rely on posting them on a mailing
list. You have to post them in a more visible place.

There should be a document with this kind of info on Avalon's site,
and it should be very easy to find.

Where is it?


Have fun,
Paulo Gaspar

> -----Original Message-----
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
> Sent: Friday, June 21, 2002 1:41 AM
> To: Avalon Developers List
> Subject: Re: [desperate plea] RE: The need for 'hints'
>
>
> Leo Sutic wrote:
> >
> > > From: Stefano Mazzocchi [mailto:stefano@apache.org]
> > >
> > > Anyway, I'm changing my -1 to the removal of
> > > lookup(role,hint) to a +0 not to interfere with A5.
> >
> > Replacing your -1 with mine.
> >
> > > As for Berin's proposal, I think that the use cases you
> > > outlined, not all of them belong to Avalon.
> >
> > Container portability is good and all, but it forces the
> > concept of what a component is to become much narrower.
>
> I'll tell you the whole truth: the very first Avalon design didn't have
> components at all.
>
> Shoking my town :)
>
> Yep, Avalon composed Blocks. Blocks were the software equivalent of lego
> bricks. Where polymorphic objects.
>
> Blocks had version, metadata dependencies, they were thread-safe, they
> were big.
>
> I remember a pretty heated discussion with Peter about the size of
> blocks. That time I even managed to change his mind ;-)
>
> Components were introduced later and were introduced mostly because the
> block patterns could be used inside the blocks as well, but where
> portability was not an issue anymore.
>
> So, we had the big reusable/sharable pieces called Blocks and the small
> pieces called Components.
>
> In short, Components were classes++, classes that followed the Avalon
> model. Since in java you want to the ability to instantiate a particular
> class, the need for hints emerged for Components (never for blocks!).
> Result: ComponentSelector.
>
> At that point I left this community for personal reasons.
>
> I come back a while after and:
>
>  1) blocks are deprecated
>  2) components are becoming blocks
>  3) direct component instantiation is considered harmful
>
> Without even noticing, the pure-COP promoters are going backwards: we
> were there already, you simply changed the name of 'block' to
> 'component'.
>
> > In Cocoon, a component can be something very small,
> > and in A5, a component will be something quite big.
>
> Gosh, things would be easier if you didn't deprecate the concept of
> 'block' and wanted to use the same name for two different things.
>
>  block -> an avalon-lifecycle-aware polymorphic object, versionned,
> fully reentrant, sharable, not directly referentiable
>
>  component -> an avalon-lifecycle-aware polymorphic object, directly
> referentiable
>
> It's evident why we wan't find agreement on how to lookup components:
>
>  lookup(role)
>
> returns a Block, while
>
>  lookup(role, hint)
>
> returns a Component.
>
> Cocoon, being itself block-like, references components. This is why it
> needs the ability to reference them directly.
>
> Phoenix/Merlin, on the other hand, being block containers, don't like
> hints because blocks are not directly referentiable (nor they should
> be!)
>
> *THIS* is, IMO, the biggest design mistake done during my absence: you
> merged two different things into one, without understanding that they
> were totally different and they only thing they shared was
> avalon-lifecycle awareness.
>
> > I'm not sure if I like that change. Much of what used
> > to be "applications using the Avalon framework" are now
> > so small that they would be individual components.
> > Don't ignore the small people, please!
>
> I agree. We should not.
>
> > Don't let Avalon
> > become something that is a heavyweight "for big jobs
> > only" framework. I'm sure there's a need for being able
> > to put small stuff into a container and have it pooled /
> > managed. That was the beauty of A4.
>
> > I'm sure we can find something that allows Avalon to scale
> > from small to big stuff.
>
> Hopefully the above will bring context.
>
> > As for the argument of use and abuse of Avalon, if someone
> > can take this framework, and produce a usable product with
> > it, how can we call that "abuse"?
>
> No, careful. Cocoon is block-like and required special treatment of
> internal components. That pushed more and more pressure on the handling
> on 'components' (using the terminology above, not the current avalon
> one) that twisted the clean design of Avalon.
>
> Removing the 'block' pillar forced too much pressure on the current
> concept of Component, leading to 'abuse' of patterns and the creation of
> inelegant solutions (like ComponentSelector, for example, which nobody
> ever liked but it was approved for need)
>
> > The way it is used in
> > Cocoon may not be what we consider proper and beautiful,
> > but it remains a fact that people have found Avalon to be
> > very useful that way.
>
> Yes, there is definately the need for two different kinds of polymorphic
> composition: direct and indirect. Direct is for small things that are
> not sharable nor interoperable, most of the time, application-specific,
> indirect is for bigger things, sharable, interoperable and fully
> reentrant.
>
> > Coming and saying "abuse! That's not
> > how we want you to use our framework" has quite a high
> > piss-off factor, migration path or not.
>
> Unless you clearly show why.
>
> > > I call for a restate of the Avalon's project charter!
> >
> > OK, so what do you propose we change it to?
>
> "restate" in my vocabulary means: 'state again'.
>
> I did in my previous email :)
>
> Hope this helps giving more context.
>
> --
> Stefano Mazzocchi      One must still have chaos in oneself to be
>                           able to give birth to a dancing star.
> <stefano@apache.org>                             Friedrich Nietzsche
> --------------------------------------------------------------------
>
>
>
> --
> To unsubscribe, e-mail:
<mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


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