[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[higgins-dev] general Registry thoughts
- From: Greg Byrd <gbyrd@xxxxxxxx>
- Date: Thu, 04 Jan 2007 11:44:25 -0500
- Delivered-to: email@example.com
- User-agent: Thunderbird 220.127.116.11 (Windows/20060909)
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
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.