Stefano Mazzocchi wrote:
>Leo Sutic wrote:
>
>>>From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]]
>>>
>>>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.
>
sounds good!
>
>
>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'.
>
Ummm, permission to raise an objection ... but I'm going to continue
reading first! :-)
>
>>In Cocoon, a component can be something very small,
>>and in A5, a component will be something quite big.
>>
Umm, another option raised .. looking at my code base I'm using some
very very small potential A5 components - and a supporting container of
no significant impact in terms of size. But lets keeps reading.
>>
>
>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
>
That changes my take a little - both are polymorphic, the differntiation
your making between block and component is that a component can be
references directly and is not associted with a version. Option to
object to the prev. assertion still in hand - but this getting more
engaging.
>
>
>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.
>
Ummm, thinking aloud ... lookup( role ) returns a component (the thing
your calling a block) and lookup( something, else ) returns an object
that looks and feels and smells like 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!)
>
Thinking to myself about the rational for Merlin in the first place ..
the ability to componse and execute a component without the overhead of
"block" a.k.a. Phoenix .. the ability to do things automatically, the
abilty to embed components and really use components whereever you want
to use them in a really free-flow manner ... what's the differnence
between a block (Phoenix style) and a component - the difference is the
contract. Yes - Merlin is a container that deals with well-formed
components, so in your defintion, yes - Merlin is dealing with blocks.
>
>
>*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 with you.
Lifecycle awarness yes - comparable semantics no.
>
>>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.
>
And we are not!
Considerable time, effort, energy is going into solving this.
>>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)
>
Given equality between your defintion of block and my idea of the
well-formed component, I do think there is a brindge between the two.
Firstly it requires recognition of the differences - which your
outlined at the beginning of this email. Secondly it requires
seperation. Our immediate challenge in this respect is the extent of
transparancy than can be achieved though implementation.
>>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.
>
Yes.
>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.
>
Yes.
(I repeating myself - eeek!)
>>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.
>
>
This is an interesting history lesson - really interesting! I'm holding
on to my objections to the points noted above, but my objections are not
really relevant to the fundimentals of your post. To me those
fundimentals your are raising can be distilled down to the recognition
of two different needs and the observation the these needs have been
folded together in the context of mutual interests - but in doing so,
the longer term implication have to some extend been compromised
something. Was the compromise justified - my guess is yes - after all
Avalon is here today and it is the best framework I know of -
compromises inclusive.
Moving onto Stefano's next email ....
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:[EMAIL PROTECTED]
http://www.osm.net
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
