[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: FW: [higgins-dev] general Registry thoughts
|
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.
