Re: [higgins-dev] configuration component requirements

[Michael McIntosh <mikemci@xxxxxxxxxx>]

I checked in several projects earlier today including:
        org.eclipse.higgins.configuration.api
        org.eclipse.higgins.configuration.common

Thanks,
Mike

higgins-dev-bounces@xxxxxxxxxxx wrote on 05/17/2007 11:22: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@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
> [image removed] 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