[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [higgins-dev] configuration component requirements
|
higgins-dev-bounces@xxxxxxxxxxx wrote on 05/17/2007 12:02:49 PM:
>
> Greg (sorry for the name mix up. No offense meant to you or Mike), Jim,
Greg shuld be flattered, though I am very upset.
> By "set", I mean to persist. I agree that the application has
> control over the contents of the iConfiguration object.
>
> A "dynamic configuration change" is the ability to change the
> ISettings in the IConfiguration and call the component to change its
> configuration run time (if the components allow). This change may
> not be persisted to the configuration store. An example is to
> request a CP to increase its connection pool size or cache size,
> based on system information.
>
> Reading a configuration store with a handler that builds the
> iConfiguration object can be agnostic of the configuration data in
> the store. Portions of the application that need read the
> configuration store and initialize a component would use one of the
> higgins supplied handlers, or write their own.
> Management of the Higgins configuration (setting and persisting
> configuration data) requires an understanding of the configuration
> data, and how to represent it to the UI (a schema and metadata).
> IConfiguration could be used for management as well by adding
> someway to get the configuration schema and passing a constructed
> iConfiguration object to a persistance handler.
>
> David
>
> David Kuehr-McLaren
> Tivoli Security
> 919.224.1960
>
>
>
> "Jim Sermersheim" <jimse@xxxxxxxxxx>
> Sent by: higgins-dev-bounces@xxxxxxxxxxx
> 05/17/2007 11:35 AM
>
> Please respond to
> "Higgins \(Trust Framework\) Project developer discussions"
> <higgins-dev@xxxxxxxxxxx>
>
> To
>
> "Higgins (Trust Framework) Project developer discussions" <higgins-
> dev@xxxxxxxxxxx>
>
> cc
>
> Subject
>
> Re: [higgins-dev] configuration component requirements
>
>
>
>
> So, there is a use case where a consuming application needs to a)
> write config, and b) have it be persistent. It could either
> implement IConfiguration itself and come up with its own set
> methods, and mechanism for persistence, or we could implement set
> methods in one or more common handlers (like in the xml file handler)
>
> Jim
>
> >>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 5/17/07 9:30 AM >>>
> I'm not sure there should be set methods either. I think we had a
> use-case for that once, but that use case may be irrelevant in this
model.
>
> If an application is passing an IConfiguration, then it implements
> the get* methods, and thus is in control of what gets "set". The
> only utility I see is if an application was able to get an
> IConfiguration somehow and needed to augment what was in there,
> _and_ the application writer was too lazy to wrap that
> IConfiguration with his own, but would rather call set* on it. But
> then, there are the dynamic/persistent issues you brought up.
>
> Jim
>
> >>> Greg Byrd <gbyrd@xxxxxxxx> 5/17/07 9:22 AM >>>
> 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
>
>
> Greg Byrd <gbyrd@ncsuedu>
> 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@eclipseorg
>
> 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>
>
> Greg Byrd <gbyrd@xxxxxxxx>
> Sent by: higgins-dev-bounces@xxxxxxxxxxx
> 05/16/2007 10:09 AM
>
> Please respond to
> "Higgins \(Trust Framework\) Project developer discussions"
> <higgins-dev@xxxxxxxxxxx>
>
> [image removed]
>
>
> To
>
> [image removed]
> "Higgins (Trust Framework) Project developer discussions" <higgins-
> dev@xxxxxxxxxxx>
>
> [image removed]
>
>
> cc
>
> [image removed]
>
> [image removed]
>
>
> Subject
>
> [image removed]
> [higgins-dev] configuration component requirements
>
>
>
> [image removed]
>
> [image removed]
>
>
>
>
>
> 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
