Re: Component Discovery and Resolution

Berin Loritsch wrote:

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


The main thing I need to confirm is if the configname value is a name 
statically bound to a component implementation class?  If yes - then 
where you describing as @avalon.configname is equivalent to what I'm 
describing as @avalon:info.name.

In Merlin this appears in the .xinfo file as:

    <type>
       <info>
         <name>some-name</name>
       </info>
     </type>

For the moment I just confirm that we are talking about the same thing.

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


Which is why your more focussed on "policy" names as opposed to 
"mechanisms" - makes sence.  More notes below - more thinking needed (at 
least by me).

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


No.  I'll be more explict.  A singleton policy (in Merlin) results in 
the establishment of a single service provider that is shared across all 
consumers within the scope of the classloader within which it is published.

>
>
>>    thread - unique per thread
>>    transient - unique per request
>
>
> AKA pooled


Nope.  Pooled objects are recycled to a pool following release.  
Transient objects are disposed of on release.

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


Sure - agreed.
I just included the subset related the <info> block as an example of the 
bigger picture.

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


They won't - keep in mind that the attributes that exist in the Phoenix 
sources (@phoenix) deal with the <blockinfo> meta descriptors.  You run 
an an task over the sources and pump out a blockinfo file containing the 
phoneix specific xinfo XML. When moving to a generic model your going to 
end up with different attributes because there will be things you will 
need to describe that are not within the existing blockinfo descriptor. 
 This means a different generation tool that may support one or more 
output DTDs.   For example you could image a tool that generates an a 
common descriptor from which native descriptors could be geenrated 
automatically.

But this does mean being aware of the big picture before starting on 
"standard" attributes for meta generation.

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


It's not as easy as that.  At the end of the day (and well after a 
Fortress release) the objective is a complete attribute declaration 
spec.  I don't believe that this will come together without working 
though the meta requirements on a step-by-step basis.  For example, Leo 
is/was close to this with respect to the discussions on the Context 
interface.  Continuing that process enables reolution of a context 
descriptor DTD and from that - you have the requirements we have to meet 
relative to tags in source files.  Phoenix work will certainly 
contribute - but it is a subset of the complete picture. The end result 
will be considation and rationalization of requirements across Fortress, 
Merlin and Phoenix.

Maybe it would not be a bad idea to look briefly at what the big picture 
looks like before standardizing anything at the avalon level.  Work I've 
been doing is hading in the following direction:

  @avalon:info.name <name>
  @avalon:info.version <version>
  @avalon:info.attribute <key> <value>

  @avalon:context <string>
  @avalon.context.attribute <key> <value>
  @avalon:context.entry <key> <type> [optional]
 
  @avalon:services.attribute <key> <value>
  @avalon:service [tag] <type>
  @avalon:service.<tag>.attribute <type>

  @avalon:dependencies.attribute <akey> <avalue>
  @avalon:dependency <key> <type>
  @avalon:dependency.<key>.attribute <akey> <avalue>

  @avalon:stages.attribute <akey> <avalue>
  @avalon:stage [tag] <type>
  @avalon:stage.<tag>.attribute <akey> <avalue>

  @avalon:extensions.attribute <akey> <avalue>
  @avalon:extension [tag] <type>
  @avalon:extension.<tag>.attribute <akey> <avalue>

Due to complaints about length emails from your's truly I'm not going to 
explain all of the above - its just an example of the scope of 
information that a big picture scenaio may need to cover.  Just for 
reference, there are additional tags that would be needed to handle 
Phoenix that are not listed above.

Cheers, Steve.

-- 

Stephen J. McConnell
mailto:[email protected]
http://www.osm.net