[higgins-dev] general Registry thoughts

[Greg Byrd <gbyrd@xxxxxxxx>]

I've been thinking about the design of a Registry that can be used for 
all of the Higgins components.  In the IdAS context, the registry will 
record known ContextFactories and the known Contexts associated with 
each of them.  The same organization can also be used for I-Card 
providers and their I-Cards.  (Are there other needs that we know about 
now?)

I propose the following goals:

1. Extensible with regard to the class of objects and sub-objects held 
in the registry.
2. Data stored in human-readable format.
3. Allows for either centralized or personalized registries (though 
perhaps not both at the same time).
4. Allows for dynamic update of info, via registration API or direct 
manipulation of stored data.
(This doesn't necessarily mean that existing, instantiated objects will 
change, but new queries will
return the updated configuration.)


My first thought is to use a directory structure, as follows:

Resource type (e.g., "ContextFactory")
-- Resource object (identified by local ID)
---- Configuration info for the resource (e.g., class name, any info 
needed for constructor, etc.)
---- Configured sub-object (e.g., a Context): a file per object

In other words, a registry will have several directories, one per 
resource type.  Each resource type will have several directories, one 
per resource.  Each resource will have a configuration file and several 
object files, one per sub-object.

The configuration info for the resource must be standard, because the 
registry needs to know how to instantiate the factory/provider.  A 
properties file could be used, which would then also allow for 
customization of the info for a particular provider.  The configuration 
files for sub-objects would be factory-specific.

One concern that I have with the above is that the ID's used to identify 
resources and sub-objects must be converted to legal file names for the 
underlying file system.  This could be awkward for a Context, for 
instance, since its ID can be a long, hairy URL.  We could hash
it to a file name, but that violates the desire to have human-readable 
info.  Another approach would be one file with all the contexts in it -- 
in this case, the file name could be simple, and the ID for each Context 
within the file could be arbitrarily complex.  This choice could be
factory-specific, or do we want to mandate a choice to simplify things 
for the user who's browsing the registry directory?

I'm also looking at Jakarta Commons Configuration 
(http://jakarta.apache.org/commons/configuration/) as a substrate for 
this.  It allows various types of configuration files (but it doesn't 
address the file naming issue).  It also allows for things like 
auto-saving and auto-reloading of files.  It has run-time dependencies 
to other Commons libraries.

Comments?  Suggestions?

...Greg