[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [higgins-dev] general Registry thoughts
|
Greg -
I like the usage of the Jakarta Commons Configuration and wonder if we
couldn't mitigate the problems you mentioned while still using the core
support. Also, I think it would be worth wild discussing an event model
that the configuration system could support which would allow clients to
register for notification of changes.
Jeff
> -----Original Message-----
> From: higgins-dev-bounces@xxxxxxxxxxx
> [mailto:higgins-dev-bounces@xxxxxxxxxxx] On Behalf Of Greg Byrd
> Sent: Thursday, January 04, 2007 11:44 AM
> To: Higgins (Trust Framework) Project developer discussions
> Subject: [higgins-dev] general Registry thoughts
>
>
> 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
>
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev
>
>
