Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Avalon Developers List" <avalon-dev@jakarta.apache.org>
From: "Stephen McConnell" <mcconnell@apache.org>
To: "Avalon Developers List" <avalon-dev@jakarta.apache.org>
Subject: RE: Resolver package--Please post your thoughts
Date: Tue, 12 Feb 2002 23:11:50 +0100
Message-ID: <001901c1b412$44e0f8d0$0a01a8c0@osm.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Importance: Normal
In-Reply-To: <3C696229.5060609@apache.org>


Berin:

Here are my thoughts concerning the Resolver.

Comparative table for Resolver/CM/SM
------------------------------------

  CM/SM provides lookup based on String
  Resolver provides lookup based on String and Query
  semantics.

              |  args         args
              |  lookup       hasThing   release
    ------------------------------------------
    Resolver  |  String       -          Token.release
              |  Query        Query      Token.release
              |
    CM        |  String       String     Component
    SM        |  String       String     Object


  Primary difference

  1. Resolver has exposure of a Query argument and Token
     return structure exposed on the interface.

  2. Resolver releases references via the token
     whereas CM/SM release references based on
     the object/component reference.

Resolver as an extension of Serviceable/ServiceManger
-----------------------------------------------------

What's missing/different?

  1. Lookup on SM returns an object which could be a Token
     (no problem), however an additional lookup( Query )
     would be needed.

  2. hasObject on SM takes an Object as an argument and returns
     a single boolean whereas Resolver returns a boolean[]
     (that's a problem but could be solved with a different
     method)

  3. SM allows decommission of a object using remove( Object )
     This isn't exposed in the Resolver interface because objects
     are removed relative to a Token.  This can be handled by
     an implementation.

Does is make sense for Resolver to extend Service manager - I
think its workable and makes sense in terms of maintaining the
current CM/SM object model.

   interface Resolver extends ServiceManager
   {
       public Token lookupToken( Query );
       public boolean[] hasReference( Query );
   }

   interface Resolvable extends Serviceable
   {
       public void setResolver( Resolver resolver );
   }

Conclusion
----------

My assumption is that your real needs over and above SM is that
you want to package a collection of references that can be
collectively removed (hence the declaration of Query and Token).
Is that a fair and reasonable conclusion?  Can Resolvable re
re-cast as an extension of SM - yes it can.  What the
benefit?  Maintenance of the CM/SM object model (which I happen
to like a lot, suits my needs, its simple and works well, and
most importantly - ensures a smooth consistent migration path).

Cheers, Steve.


> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: Tuesday, 12 February, 2002 19:43
> To: avalon-dev@jakarta.apache.org
> Subject: Resolver package--Please post your thoughts
>
>
> I have tried to address all the shortcommings of the
> ComponentManager/ComponentSelector
> approach in the Resolver package.  (located in Avalon Framework
> src/proposals directory).
> If you find that this package does *not* support your needs, or
> appears clumsy/difficult
> to use, please air your grievances now.
>
> Please either take the approach of fine-tuning the interfaces or
> of providing an alternative.
> It also helps when you state the reasons why you beleive your
> alternative is better :)
>
> Since everyone is keen on removing the necessity of marker
> interfaces sooner than later,
> I want a smooth migration path.  That means that we need a
> replacement for Component
> resolution (without the Component interface).
>
> It also means that we should do the following:
>
> * Promote ComponentHandler interface and implementations to Framework
> * Provide standard mechanism for registering a Component with a handler
>     - ComponentInfo? (like BlockInfo)
>     - Manifest entries?
>     - Other?
> * Finalize Resolver framework, or whatever the replacement ends up being
>
> If this seems like a winning migration path, and we really like
> this approach, we can make
> it a part of Framework 4.2 or something like that.  It is
> important that we have working
> implementations though.
>
>
> --
>
> "They that give up essential liberty to obtain a little temporary safety
>   deserve neither liberty nor safety."
>                  - Benjamin Franklin
>
>
> --
> 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>