avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@osm.net>
Subject Re: Fresh Outlook: (was RE: [desperate plea] RE: The need for 'hints')
Date Tue, 25 Jun 2002 16:44:24 GMT


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()
>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 id="unit2" class"UnitImpl">
>  <!-- unit2 configuration -->
><!-- ... -->
><component id="controller" class="UnitController">
>  <!-- 
>    ...
>    <unit name="unit1"/>
>    <unit name="unit2"/>
>    ...
>  -->
>(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
>  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?
>On Mon, 24 Jun 2002, Berin Loritsch wrote:
>>Date: Mon, 24 Jun 2002 15:30:49 -0400
>>From: Berin Loritsch <bloritsch@apache.org>
>>Reply-To: Avalon Developers List <avalon-dev@jakarta.apache.org>,
>>     bloritsch@apache.org
>>To: 'Avalon Developers List' <avalon-dev@jakarta.apache.org>
>>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:stefano@apache.org] 
>>>Ok, this said, let's move on. I see two different ways of 
>>>looking for a
>>> 1) I need something that does this.
>>> 2) I need something that does this, and should work in this context
>>>Two real life examples:
>>> composer: I need a component that implements 'screwdriver'
>>> componentManager: here it is
>>> 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
>>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
>>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
>>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>


Stephen J. McConnell

digital products for a global economy

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

View raw message