[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [higgins-dev] configuration component requirements
|
Mike,
Commenting on this quote from bullet
2, "As it is now, IConfiguration only has get methods" and all
of bullet three.
I thought the goal of the configuration
component was to separate the storage of configuration data from the initialization
of the components, such that the components would not have a dependancy
on a specific format for saving the config data. From a tooling and exploiters
perspective, applications will need to edit and set configuration of components.
The application should have the option of the format to store the data,
but Higgins could provide base providers for the configuration store (properties
file, etc.).
I see the runtime aspect of passing
configuration to a component for initialization, or dynamic configuration
change a separate component from the ability to read from a configuration
store, and separate from the ability to set a configuration store.
David
David Kuehr-McLaren
Tivoli Security
919.224.1960
Greg Byrd <gbyrd@xxxxxxxx>
Sent by: higgins-dev-bounces@xxxxxxxxxxx
05/17/2007 09:38 AM
|
Please respond to
"Higgins \(Trust Framework\) Project developer discussions"
<higgins-dev@xxxxxxxxxxx> |
|
|
To
| "Higgins (Trust Framework) Project
developer discussions" <higgins-dev@xxxxxxxxxxx>
|
|
cc
| higgins-dev-bounces@xxxxxxxxxxx
|
|
Subject
| Re: [higgins-dev] configuration component
requirements |
|
The way I understand it, the object is a standard holder
of configuration settings. The other components can use it how and
when they want -- they'll need to have a configure method that takes in
an IConfiguration object. So I think this would work either way.
If an already-initialized component has its configure method called,
it could say "No, I'm already configured," or it could accept
the new information and reconfigure dynamically.
What we're standardizing is the way to pass such information in, so that
(a) it's programmatic, rather than file-based, and (b) each component does
not need to define its own data structure for doing this.
(Again, this is what I thought I heard -- others can correct me, if I'm
wrong.)
...Greg
Anthony Nadalin wrote:
So I have not looked at code but is this also for runtime
config or just initialization configuration ?
Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
Greg
Byrd <gbyrd@xxxxxxxx>
I'm trying to nail down requirements for the Configuration component. I've
looked at Mike's configuration code for the STS, and I think I understand
it fairly well. I'm not quite sure what should be carried over into the
cross-cutting component, and what should be generalized.
What I'm thinking so far (and most of this comes verbatim from Mike's code):
(1) An ISetting interface that encapsulates a name, a type, and a value
(all strings) for a configuration setting.
(2) An IConfiguration interface, so that objects of this type can be passed
in to component-specific configuration methods. As it is now, IConfiguration
only has get methods -- to get a single ISetting, or the Map (where ISettings
are indexed by name), or an iterator over the Map.
(3) Should we then provide a set of implementations that convert data from
various forms to the map described above? For example, Mike's ConfigurationHandler
and the other various SettingHandler types allow an XML file/stream to
be parsed. Should this be in the Configuration component, or is it specific
to STS? Should we create other components, such as a property file reader,
or should this be done on an as-needed basis by different component owners?
...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
_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev
