Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [higgins-dev] configuration component requirements
 
>        org.eclipse.higgins.configuration.common
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.higgins/plugins/org.eclipse.higgins.configuration.common/committer.psf?root=Technology_Project&view=co


>>> Michael McIntosh <mikemci@xxxxxxxxxx> 5/17/07 9:32 AM >>>
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

_______________________________________________
higgins-dev mailing list
higgins-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/higgins-dev

Back to the top