Robert Mouat wrote:
>Steve,
>
>yes, what I described is more of an application composed of a hierarchy of
>functional units (and that hierarchy, while defined by configuration,
>remained static for the applications life)... however I think that avalon
>should support this sort of hierarchy because of what happened next with
>some of the components that were used in it...
>
Just so I get my own terminology a little better qualifier - this is
what I am
refering to when I use the term application and container:
application
an interface that exposes services that
may be provided to a client and/or child
applications
container
an implementation of an application that manages that
establishment of services possibly in collaboration
with a parent application
>
>In the example I described below the controller and units were not at the
>top or bottom of the hierarchy (the units produced data, so had a
>dependence on a DataCollector which had to be unique for each unit)... The
>application had a lot of other pieces, some related to the functionality
>of the user interface...
>
No problem - this is classic component dependecy stuff if I understand
correctly.
>
>The framework (developed in-house) was suitable for such an application
>(hierarchy of functional units and scoped names)... Later they thought -
>"wouldn't it be good if we could use some of our components in a webapp
>since we want the web user-interface to share some functionality with the
>application user-interface" (though obviously not the same look-and-feel).
>
>Unfortunately the design of the framework prevented this (it used static
>methods to fetch global configuration that would not be global in a
>webapp)... [disclaimer: I wasn't around when the framework was designed
>:)]
>
>The point is that what is a 'function unit' within an application could
>also become a component in a different setting
>
Absolutely.
>(though as I said not with
>the framework that was used).
>
>
>Basically there are 2 reasons to allow avalon to support using components
>as 'functional units' and having name scoping:
>
>1. so that when writing such an application you can re-use existing
>components as your functional units.
>
Yep.
>
>2. having written such an application, your functional units can be used
>as components elsewhere.
>
Yep
>I'd like to finish with a rant:
>
><rant subject="Assembler as God">
>
>[by assembler I'm referring to the person who puts the final application
>together - including things like writing the code for a programatically
>assembled container (like fortress), and writing a cocoon sitemap].
>
>The framework describes a contract between a component and a container -
>this is good for both component writers and container writers... but
>components and containers are both subject to the whims of the assembler.
>
Yep.
>
>The assembler gets the last say. The assembler puts everything together
>to form the final application - choosing components and the container to
>suit their needs. [though perhaps not always with a choice of container]
>
>If a component/container isn't flexible enough then the assembler can
>choose another (or potentially write one).
>
That's the idea I have in mind - different containers doing different
things but a particular cointainer does its particular thing right.
Eliminate the issue of onoe container for all - instead - leverage the
right tool for the job.
>
>I think that this should be recognised in how a component is looked up -
>i.e. when a client asks for a particular role, the assembler should be
>able to specify exactly what component it gets.
>
>
Where an assembler is assemberling the content of an application and the
ingridients are classes and profiles - then yes. I agree. When the
ingridients are services from somewhere else - then the assembler has to
live with the service requested based on the quality of the container in
support of a particular idea of service defintion and fitne4ss-for-purpose.
>In that respect components only get to demand what they need in terms of
>interfaces -- anything else they have to humbly request from the
>assembler, and not complain when denied.
>
>
Yep.
>
>e.g.
>
>If a component asks for a tcp connection, then suggests that it should be
>SSL - I, as assembler should be able to say "denied: your connection will
>be tunnelled via ssh instead" -- of course if the component had requested
>a 'secure' connection, the request would have been approved (or not if it
>is in a development/testing environment).
>
Not ready to agree on that just yet. Personally I hate the notion of
"suggestions"and "hints" - these notions don't exist in the framework
and it has not been formalized anywere else - and until that happens ...
don't expect way cool solutions.
>
>Now suppose that the component and the container are conspiring against
>me, the assembler - and the component tells the container (via metadata)
>that it insists that the connection be SSL, and the container decides to
>enforce that... well I could write a small wrapper component that lied to
>the container saying that it provided an SSL connection, but instead
>simply used another component that provided an unencrypted tcp connection
>that happened to go through a VPN tunnel.
>
>I am the assembler, I always win :)
>
>
I'm not really following the above too well.
The guy doing the assembnly is simply working with the
constraints/limitations of the language used by a particular container.
You wind to the extent that you (a) choose the appropriate container as
a deployment vehicle, and (b) leverage the container to the best of its
ability.
>
>Anyway, the point is that the framework should recognise the role that the
>assembler plays and not try to limit the assemblers ability to chose what
>components client get for particular roles -- the assembler is the only
>one who can see the 'big picture'.
>
A container brings God down to earth because the container knows about
reality.
God's just speculating :-)
>
>If a component really, really, wants an SSL connection then it can always
>embed one inside itself.
>
>[of course metadata can be useful, if the assembler is lazy and the
>container has to guess what component to give the client]
>
>
On the subject of laziness - assemblers should be given the right to be
lazy.
Developers on the otherhand cannot - we can give the developer tools -
and we give the developer a hard time when things are not done correctly
- and we deliver a buch of solutions that make life an enjoyable process.
Cheers, Steve.
<standard-disclaimer>
Nothing stated above has anything to with anything - just random noise. :-)
<standard-disclaimer>
></rant>
>
>Robert.
>
>
>
>Stephen McConnell wrote:
>
>
>
>>Robert:
>>
>>Thinking-out-load ...
>>
>>Relative to my current thinking and work I'm currently doing related to
>>containerkit, what you are describing below is an application. It's an
>>application because you are describing the "content" of a functional
>>unit. In the example, your using a single class as the base (but this
>>is semi-academic). In effect you are describing a series of type
>>profiles based on a single class. Each profile represents the
>>association of a base type with criteria concerning the deployment of
>>the type. These profiles are named such that each name is unique within
>>the application context (which is different to role names in a component
>>type context).
>>
>>Your client component needs to declare a dependecy on the controller
>>application and once that has been resolved via lookup, it then get the
>>service you want using the profile name as the key in the application
>>scope of the controller (or any other application specific method you
>>choose). That operation is specific to the application at this time.
>> However, there is thinking going on about how application/container
>>hierachies could be managed - which would potentially enable your lookup
>>operation to be directed to the application in which the name is scoped
>>- but that's pure speculation at the moment so don't ask too many
>>questions just yet! Like I said ... thinking-out-load.
>>
>>Hope this helps.
>>
>>Cheers, Steve.
>>
>>
>>Robert Mouat wrote:
>>
>>
>>
>>>I have a use case (from previous work I did in a non-avalon framework)
>>>that I'm not sure how to reconcile with the current metadata/lookup()
>>>proposal...
>>>
>>>basically there are two issues:
>>>1. multiple components coming from the same class (with different configuration).
>>>2. passing role names into a component via configuration.
>>>
>>>The situation is that I have a controller, that controls multiple units
>>>(so that they can work together) -- the number of units it controls (and
>>>how they work) is specified in the controller's configuration. The units
>>>are generally all going to be of the same class but with different
>>>configuration (e.g. different ports).
>>>
>>>so I will have something like:
>>>
>>><component id="unit1" class="UnitImpl">
>>> <!-- unit1 configuration -->
>>></component>
>>>
>>><component id="unit2" class"UnitImpl">
>>> <!-- unit2 configuration -->
>>></component>
>>>
>>><!-- ... -->
>>>
>>><component id="controller" class="UnitController">
>>> <!--
>>> ...
>>> <unit name="unit1"/>
>>> <unit name="unit2"/>
>>> ...
>>> -->
>>></component>
>>>
>>>(This is perhaps not too dissimilar in concept to a cocoon sitemap).
>>>
>>>In an ideal situation I'd like the controller to be able to do something
>>>like:
>>>
>>> unit[i] = (Unit) lookup( unitNames[i] );
>>>
>>>where unitNames[] comes from the configuration and is something like
>>> { "unit1", "unit2" /* ... */ }
>>>
>>>It is impossible for the controller to declare these dependencies in
>>>metadata - since they aren't known until assemble time.
>>>
>>>Now I don't fully understand how the current metadata proposal governs
>>>component resolution, but I get the impression that I can't write the
>>>above in a container independent way (and hence not in a reusable way)...
>>>I could probably use a Selector (e.g. lookup("unit-selector")), but then
>>>the Selector would have to be container specific for the same reasons.
>>>
>>>The reason I'm not sure that this will work is that when I look over the
>>>emails regarding metadata/lookup() it seems that the job of the assembler,
>>>as far as determining a mapping from role names to components, is absent
>>>-- maybe it was just assumed (and not explicitly mentioned).
>>>
>>>What I'm looking for is some assurance the the job of the assembler isn't
>>>going to be replaced by metadata.
>>>
>>>Am I misunderstanding something about the metadata/lookup() proposal? is
>>>it possible to write such a beast in a container independent way?
>>>
>>>- or -
>>>
>>>is 'controller' really a block (or the controller+units a single big
>>>component)? And it should embed Fortress (or another container), and take
>>>in all the configuration for the units as well as it's own configuration?
>>>
>>>Robert.
>>>
>>>On Mon, 24 Jun 2002, Berin Loritsch wrote:
>>>
>>>
>>>
>>>
>>>
>>>>Date: Mon, 24 Jun 2002 15:30:49 -0400
>>>>From: Berin Loritsch <[EMAIL PROTECTED]>
>>>>Reply-To: Avalon Developers List <[EMAIL PROTECTED]>,
>>>> [EMAIL PROTECTED]
>>>>To: 'Avalon Developers List' <[EMAIL PROTECTED]>
>>>>Subject: Fresh Outlook: (was RE: [desperate plea] RE: The need for
>>>> 'hints')
>>>>
>>>>While Stefano has some important points, we do have to bring practice
>>>>into view. An abstraction without foundation in reality is doomed to
>>>>failure. So let's look at this pragmatically.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]]
>>>>>
>>>>>Ok, this said, let's move on. I see two different ways of
>>>>>looking for a
>>>>>component:
>>>>>
>>>>>1) I need something that does this.
>>>>>
>>>>>2) I need something that does this, and should work in this context
>>>>>
>>>>>Two real life examples:
>>>>>
>>>>>1)
>>>>>composer: I need a component that implements 'screwdriver'
>>>>>componentManager: here it is
>>>>>
>>>>>2)
>>>>>composer: I need a component that implements 'screwdriver'
>>>>>and I'll use it on screws of 3 mm of diameter.
>>>>>componentManager: here it is
>>>>>
>>>>>It has been suggested that the working context is just
>>>>>another information you pass in the role, so, in our
>>>>>examples, we would have an inflation of roles for each
>>>>>screwdriver and each possible screw size or size ranges.
>>>>>
>>>>>Please, tell me, am I the only one who doesn't get a good
>>>>>feeling out of this?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>In the hardware realm for ordinary household projects, you
>>>>only have to worry about three basic sizes of screwdrivers
>>>>and two different types. There are Philips head and Flat
>>>>head screwdrivers. They come in three sizes (#1, #2, #3).
>>>>For 90% of woodworking projects you use a Philips #2. For 90%
>>>>of electrical projects you use a Flathead #2 (or #1).
>>>>
>>>>The bottom line is that while there are many different
>>>>possibilities of roles, only a couple are really necessary in
>>>>a system.
>>>>
>>>>For projects like Cocoon where the Sitemap is not only the
>>>>container for its components, but it also chooses the
>>>>component necessary for the job, it is really better for the
>>>>Sitemap container to choose the component in a Cocoon specific
>>>>way.
>>>>
>>>>What you are accusing Peter and company of doing is not really
>>>>any different than what Cocoon does. The lookup might change
>>>>
>>>>
>>>>from Generator.ROLE, "hint" to Generator.ROLE + "/constraint",
>>>
>>>
>>>>but the general outcome is the same. There is *essentially*
>>>>ten different roles if we are being true to what it conceptually
>>>>is.
>>>>
>>>>To the pipeline, A generator is a generator is a generator.
>>>>To the sitemap, we may have ten different implementations that
>>>>we choose from. The *sitemap* chooses which of those 10
>>>>generators are used depending on context. Because it is a
>>>>container in and of itself, it can do so in any way it chooses.
>>>>Effectively each individual Generator performs a different role.
>>>>One pulls info from the filesystem, another pulls it from an
>>>>external site, and yet another will pull it from a database.
>>>>The pipeline doesn't care, but the pipeline doesn't (or shouldn't)
>>>>directly request the generator. The sitemap sets the generator.
>>>>
>>>>So for real practicality's sake, we either have a distinct
>>>>role for each of the Generators or we have a smart container.
>>>>
>>>>Think of it in terms of the Chorus in a theatrical play. They
>>>>act as one, but they have their own part to play in the harmony
>>>>or narration of the play. There might be three distinct people
>>>>on the stage at one time that perform the same general function.
>>>>It is the same with the concept of generators in Cocoon.
>>>>
>>>>Please tell me if I have confused you more than I have clarified
>>>>things.
>>>>
>>>>
>>>>--
>>>>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]>
>>>
>>>
>>>
>>>
>>>
>>--
>>
>>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]>
>>
>>
>>
>>
>
>
>
>--
>To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
>
--
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]>
