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

[Valery Kokhan <vkokhan@xxxxxxxxxxxxxx>]

Hi Greg,

I agree that should have a standardized location for the factory's
configuration info. What I can't really understand is why are you
thinking we need a way to map factory ID with its class name?

-- 
Thanks,

Valery

Friday, January 12, 2007, 5:47:44 AM, you wrote:

> My responses to Valery inline, preceded by GB:

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

> GB: OK. 

> <snip>

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

> GB: We at least need a way to connect a factory ID with its class name.
> At that point, you're right -- we can instantiate with no parameters and
> have the factory initialize itself.  Wouldn't it then be useful to at least
> have a standardized location for the factory's configuration info?  Otherwise,
> this has to be embedded in the code, which means that the person installing/
> deploying the factory has to look at the code to figure out where to put
> the configuration info.

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

> GB: I'm coming to the same conclusion.  The disadvantage is that the
> factory (or a user) may have to scan the whole file to know if something
> has changed, or to find the info for a particular sub-object.

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

> GB: Yes, I understand that's a concern.  



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