Addendum to RunJob Meeting, March 3, 2004
-----------------------------------------

** -denotes specific tasks assigned at the meeting

Discussion of Configurator naming and namespace resolution.
(Dave Evans, Peter Love, Greg Graham)

While Peter was still in town, we had a brief meeting on the 
Configurator naming issues.  Dave has found a problem with the 
current way of doing things. 

(a) ConfiguratorDescriptons

    A ConfiguratorDescription contains five fields: Class, Version, 
  Alias, AppFam, and DataTier.  Greg has said that it is this way for
  historical reasons and clearly needs to be extendible.  He proposed 
  that the ConfiguratorDescriptions contain three kinds of fields: 
     (1) Required by system, user cannot change values.
         These are the tags "Class" and "Version".  These are set by
         the ConfiguratorFactory.  
     (2) Required by system, User settable.
         This is the tag "Alias".  The system need here is to distinguish 
         multiple configurators of the same "Class" and "Version".  Only
         one tag is needed for this purpose.
     (3) User defined and User settable. 
         These are tags that the user adds to model the application
         being described by the Configurator.  The big problem is that
         there is no (easy) interface to add/change these tags, so we are
         stuck with the historical defaults DataTier and AppFam.  Also 
         useful for developers who want to create possibly complex 
         dependencies right in the constructor. 

  Resolved: 
     (1) We will immediately move to a minimal schema (Class, Version, Alias)
         and remove the "historical" defaults.
     (2) We will design and add interfaces to add/modify description tags.
     These are considered to be small changes to the codebase.

(b) Requirements (or Dependencies) 

       A Configurator models some kind of dependency relationship by 
     maintaining a list of ConfiguratorDescriptions.  A ConfiguratorDescription
     in the dependency list can be used later as a key to look up a specific
     Configurator attached to the Linker.  For example, the algorithm for 
     Configurator to Configurator lookup is as follows: 
         (1) A reference including a fragment of a ConfiguratorDescription
             is presented to the requesting Configurator.
         (2) The requesting Configuartos matches this description to a 
             unique description in its dependency list to resolve the 
             fragment to a fully qualified ConfiguratorDescription. 
             (Usually, "Class" is resolved to "Class,Alias".) 
         (3) The fully qualified ConfiguratorDescription is used as a key 
             to resolve a concrete reference to a target Configurator in the 
             Linker.
         (4) The Linker does a parameter lookup on the target.

        Dave found a potential problem with this algorithm.  If the original
      reference containing the ConfiguratorDescription fragment contains
      tags that are different than the ones used in the dependency list
      of a soource Configurator, the original reference may be rejected
      even if it points to a valid Configurator. ("Misaligned Tags") 
      Note that the chances of this happening are less if we use only the 
      minimal schema as resolved above.  However, Dave also has specific 
      modeling requirements that run into exactly this problem down the road 
      when many User defined tags are present.

    Resolved: 

        We will design a ConfiguratorReference class that will handle the 
      details of name resolution.  The matching functionality will be moved 
      into this class as well. Matching requires an extra argument specifying 
      which tags matter in the matching operation.  The problem of misaligned
      tags will be adressed here by doing extra lookups (possibly cached) 
      designed to determine if two misaligned references point to the same 
      Configurator, and this becomes the crucial test for reference resolution.
      This class (ConfiguratorReference: Phase I) will be designed to wrap 
      ConfiguratorDescriptions one to one.  This is considered to be a large
      but straightforward change to the codebase. 

(c) Enhanced ConfiguratorReference (Phase II: long term planning)         

        The ConfiguratorReference may also wrap the Configurator itself.  
      This would keep all of the above functionality of managing Configurator 
      to Configurator references and ConfiguratorDescription matching.  In 
      addition, the ConfiguratorReference would add a layer of indirection 
      to Configurator referencing itself that would allow: 
        (1) Different communications protocols to be established between
            Configurators.  This would be a logical place to put a Web 
            services implementation, for example.
        (2) Multiple ConfiguratorReferences per Configurator.  This would 
            further enhance a wide class of Web Services models.

      Resolved: 
        It is not yet clear exactly what this would be used for, but there
      is a widespread feeling that it supports a wide class of Web Services
      models. For example, sitautions where Configurators can be instantiated
      on demand, at remote sites, or shared among processes would be  
      supported by this feature.  Phase II is considered a large change, and 
      we want to break this up into steps to ease integration pain.
        Step 0: Complete design work and use case analysis.
        Step 1: ConfiguratorReference supports only local, in-process 
            communication.  ConfiguratorReferences are 1-1 with Configurators.
        Step 2: ConfiguratorReference supports 1-N relationships within a
            single process.
        Step 3: Configurators can be instantiated on demand within a single
            process.
        Step 4: Distributed confiugrators.

      The latter steps are at this point considered more speculative, but 
      we feel that some prototyping can already take place on the earlier 
      steps.  (Dave)