Don't blame Mike for that initial email -- it was mine.
I wasn't sure about setters on the configuration object. (This is the
kind of feedback I'm looking for.) But then we have the issue of
whether the dynamic setting is meant to be persistent (stored) or
temporary.
I agree with the principle, however -- the configuration component
should insulate the other components from configuration data format
issues.
I'm not sure I'm able to parse your last statement. Are you saying
that there should literally be separate components for these three
activities? Or that the proposed Configuration component should
address all three with distinct interfaces?
...Greg
David Kuehr-McLaren wrote:
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
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
|