Re: Component Discovery and Resolution

Stephen McConnell wrote:
> 
> 
>>
>> @avalon.configname  Maps to the shorthand name we use in our
>>                     configuration files.
> 
> 
> 
> I think this is Fortress specific.  Phoneix resolves configuration 
> fragments based on block names in the assembly file.  Merlin resolves 
> configurations at multiple levels (type, profile, and block).  However, 
> see notes towards the end of the reply.

I understand, and can make it happen that way.  However I *really* don't
like instance based short names.  An XML element should stand for the
same implementation all the time.  It makes it really simple to
understand.


>> @avalon.scope       Maps to a set of constants ("container",
>>                     "thread", or "request") to represent the
>>                     type of lifestyle it must support.
> 
> 
> 
> I'm a little confused on this one - if we are talking about lifestyle 
> then should this not be something like [singleton|thread|pool|transient] 
> (using Merlin terminology here).  The [container|thread|request] set 
> seems to be referring to something different.

We currently have no standard on this.  I would like to push toward a
standard--without forcing implementation types.


>> Alternatively if you absolutely have to specify the handler
>> by the long name, you can use the @fortress.handler attribute
>> instead.
> 
> 
> 
> Ok - I getting the impression that we are talking about lifestyle in 
> which case what is the correlation between Merlin and Fortress here? 
> This is the Merlin summary:
> 
>    singleton - unique across a virtual machine

Correction: unique across a container.

>    thread - unique per thread
>    transient - unique per request

AKA pooled

> This is definately specific to the Fortress/ECM notion of shorthand name 
> mappings which are basically keys to data entries.  If I understand 
> correctly, the shorthand name is a equivalent to the name of the 
> component (or in Merlin terms, the name assigned in type info 
> declaration).  If that's correct, the equivalent in Merlin type info 
> structure looks like:

Keys to data *types* which is much more clear.

> @avalon:info.name <name>
> @avalon:info.version <version>
> @avalon:info.attribute <key> <valaue>
> 
> Where avalon:info.name equates to Fortress/ECM shorthand name?
> 
> One other thing, in the background work I've been doing I'm using the 
> URN convention of <domain>:<key> - i.e. "avalon:something.whatever.etc". 
> The benefit here is that you can use the domain to establish a 
> dictionary of keys.

Yes, but we need a dictionary of keys that our users can build upon.
I would like to get the minimal set done now--which ignores validation
arbitrary attributes and version info.  Just enough to tell the
container what is available.

You see, merlin and phoenix seem to have their own set of naming
conventions.  I would really prefer if our users don't have to do
a global replace on all the attribute names when they upgrad from
Fortress to Merlin or Merlin to Phoenix.

Keep in mind that Phoenix has been doing the attributes the longest,
so I would tend toward using their conventions.