Re: FW: [higgins-dev] general Registry thoughts

[Valery Kokhan <vkokhan@xxxxxxxxxxxxxx>]

Hi Greg,

See my thoughts in-line.

-- 
Thanks,

Valery

Wednesday, January 10, 2007, 6:53:56 PM, you wrote:

> I have not had a moment to read this and respond. 
> What are your thoughts?

> -----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?)

With regards to other needs I think we'll registry for the stuff what
we call RPPS 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.)

With regards to goals I also thought of an ability to automatically
discover and load newly added plugins at runtime (like eclipse does
with extension points).

> 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.

I do not think it is really necessary that configuration info for resource
must be standard. Configuration info is necessary rather to initialize
then to instantiate factory/provider and thus, registry may know nothing
about configuration file format.

> 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'd prefer second approach where factory configuration and context
configurations are stored in the same factory-specific file.

> 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.

Probably it would be a good idea to use Jakarta Commons Configuration
as a substrate but I think not right now. Locking how things are
going with legal approval of other libraries I do not think that we
can afford ourself such luxury for such critical component like
registry.

> Comments?  Suggestions?

> ...Greg

> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev

_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev