********************************************************************************
*** Last-Modified: $Date: 2001/03/14 05:43:35 $ 
*** Version: $Id: TODO,v 1.16 2001/03/14 05:43:35 burton Exp $
*** Author: Kevin A. Burton ( burton@openprivacy.org )
********************************************************************************


- go over all the code and make sure it is threadsafe.  What are we doing about
  setting the PropertyManager from within the ComponentHandle.  If we do this
  will end up with tainted properties.  It might be a good idea to clone the
  handles before we use them.


  - Need to have an implementation of the Java Versioning Specification within
    components. http://java.sun.com/j2se/1.3/docs/guide/versioning/spec/VersioningSpecification.html

    - can we provide this information with standard 
    
    Component meta-info
              Interface -> title, vendor, description, version 
              Implementation -> title, vendor, description    
              
        Major version numbers identify significant functional changes.
        Minor version numbers identify smaller extensions to the functionality.
        Micro versions are even finer grained versions.


    getImplementationTitle()
        Return the title of this package.
    
    getImplementationVendor()
          Returns the name of the organization, vendor or company that provided this implementation.

    getImplementationVersion()
          Return the version of this implementation.

    getSpecificationTitle()
          Return the title of the specification that this package implements.

    getSpecificationVendor()
          Return the name of the organization, vendor, or company that owns and maintains the specification of the classes that implement this package.

    getSpecificationVersion()


  - We need a new method in Component and ComponentHandle, getLifetime()... this
    could return a Lifetime object and if it is null it is up to deployment what
    the lifetime is.  This can be used so that a Component can REQUIRE that a it
    has a certain lifetime.  The Lifetime object should have a method
    getInstance() which would return one of its known instances.  

  - Make sure to warn(and disallow) if Talon has registered more than one component with the
    same name.

  - Should I move the talon.properties file over to an XML based configuration?
    Hopefully something based on keys and XPATH???

  - BUG!  HandleManager should not be able to serve up SINGLE Handles based on
    interface.  It is possible that we can have multiple implmenentations
    registered which implement the same interface.  Duh!!!

    - this mechanism should be fixed so that we can specify a default component
      for a interface or serve them based on reputation. 
    
  - should we build a simple assertion mechanism from Arrowhead????  Maybe
    Arrowhead should use Talon and then it will get assertions?
    
  - does Talon need to pay attention to uuids?  How should we handle unique
    objects and their pet names.

  - need support for importing another talon properties files.  This could be a
    list of import.0 import.1, etc.z 

  - Ability to specify that an object needs instantation ASAP.  (when Talon
    first starts up).  This should increase performance of objects due to
    reduced component instantiation time.

  - Talon should be able to use its own Components without causing holes in the
    system?????

  - Initializes itself on request.  Basically just a snap-in library that any
    application can use.

                
  - ObjectPool

      // get the number of objects available for use.
      - getFreeInstanceCount()

      // total number of objects being used elsewhere...
      - getUsedInstanceCount()

      // get the maximum number of objects to serve.
      - getMaxCount()

  - Object count handling.  Singleton, handle (one singleton per handle) or
    Named Singleton, pooled (100, 200, etc), infinite (handled by the garbage
    collector)...
