[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [higgins-dev] run-time configuration changes
|
Hi,
Here are some thoughts:
1) Instead of introducing the new method setConfigurationHandler(), wouldn't it be better to pass the IConfigurationHandler as an additional parameter to the configure() method?
2) Is there really a namespace "com.ibm.higgins.configuration.api", or is that a mistake? :)
3) So the applyUpdates() method would basically write the whole "mapGlobalSettings" back to a file, right? In theory I guess it would be nice to be able to write only a part of the configuration back (i.e. just the part that concerns your own IConfigurableComponent). E.g. have a method applyUpdates(...something-here-that-identifies-a-part-of-the-configuration...). In cases where writing parts of the configuration is the same effort as writing the whole thing (e.g. in the case of the XML ConfigurationHandler), that method could simply call the "main" applyUpdates().
4) Shouldn't the ISetting.addChildSetting() method return the new ISetting? Then you wouldn't have to search for it afterwards with a for loop.
5) I like the idea that you don't HAVE to provide an
ISettingDescriptor, i.e. it can be built automatically when the
configuration is read.
6) If you want to implement an ISettingDescriptor, how would you do
that? Would IConfigurableComponent have a method getSettingDescriptor()
?
7) I don't really understand the difference between Option 1 and Option 3.
8) I do like the ISettingDescriptor idea slightly better than the ISetting idea, but both are great ways of solving the problem I think.
BTW if you're interested, Dmitry made a configuration frontend for the SAML2 IdP:
http://graceland.parityinc.net/saml2idp-server-config
But it's a very specific solution and probably not too useful as a basis for a "general purpose" configuration frontend.
Markus
On Tue, Jul 15, 2008 at 8:39 PM, David Kuehr-McLaren <
dkuehrmc@xxxxxxxxxx> wrote:
I apologize if I sent this twice to
the list. My email program says I never sent it.
With much help from Greg Byrd and Rajalakshmi
Iyer I have collected the discussions on Configuration Management and created
a proposal page on the Wiki
http://wiki.eclipse.org/Higgins_Configuration_Management
It contains the general proposal and
three options to consider. I am leaning toward option 3, which is a hybrid
of the first two options. Please let us know you comments.
Thanks,
David
David Kuehr-McLaren
IBM Tivoli Security
919.224.1960
David Kuehr-McLaren/Raleigh/IBM@IBMUS
07/07/2008 03:55 PM |
|
To put the need for the "constraints" in to context of a use
case: Application owner uses a UI (CLI and/or GIU) to configure an
instance of a context provider. With the UI, and application owner can
the context provider for the parameters it needs to configure an instance
of the provider. The UI will present a form to collect the configuration
data, and be able to persist the new configuration. The UI will also
be able to display existing configurations and allow the user to update
and delete CP configurations.
The UI application needs away to understand the model of the configuration
data needed by a context provider.
David
David Kuehr-McLaren
Constraints are extra information about the setting that limit the potential
values for that setting. Could be min/max, could be a set of legal
values, etc.
It's basically a "punt" to avoid over-specifying what can be
represented by a
descriptor. Constraints are somewhat component-specific, though I
can imagine
there are a significant set of common constraints that can be captured
in a base
class.
I have not figured out how and when constraints are enforced. The
idea is to
provide a management client some hints about how to construct a proper
value for
a setting.
The setXXX and addXXX methods are intended for building up the
SettingDescriptor. I don't intend that you get a component's SettingDescriptor
and then start making changes to it. But someone's got to create
the descriptor
in the first place. Is there a better way to specify this -- in some other
interface, for example?
...Greg
Michael McIntosh wrote:
> Greg,
>
> Can you provide more information about the "Constraints"
in the
> ISettingDescriptor?
> Can you explain why there is code to dynamically change the
> ISettingDescriptor? (seems like when a component changes what settings
it
> expects it justifies a restart)
>
> Regards,
> Mike
>
> higgins-dev-bounces@xxxxxxxxxxx wrote on 07/07/2008 12:54:48 PM:
>
>> [image removed]
>>
>> [higgins-dev] run-time configuration changes
>>
>> Greg Byrd
>>
>> to:
>>
>> Higgins (Trust Framework) Project developer discussions
>>
>> 07/07/2008 12:57 PM
>>
>> Sent by:
>>
>> higgins-dev-bounces@xxxxxxxxxxx
>>
>> Please respond to "Higgins \(Trust Framework\) Project developer
> discussions"
>>
>> As discussed in our last phone meeting, a group at IBM has a need
to
>> instantiate
>> configurable components, and to make their configurations persistent.
I
>> promised that I would send some mail to the dev list to (hopefully)
>> kick off a
>> conversation.
>>
>> This particular requirement raises at least two issues:
>>
>> (1) Asking a configurable component about its configuration settings.
> The
>> ISettingDescriptor interface was a first effort at this capability,
>> but it never
>> got further than that. Assuming that ISettingDescriptor
is
>> descriptive enough,
>> there needs to be some mechanism to describe the settings and
>> constraints for a
>> particular component type.
>>
>> That's what this discussion was about:
>> http://dev.eclipse.org/mhonarc/lists/higgins-dev/msg04721.html
>>
>>
>> (2) Once we create the setting for a component, how do we write
the
>> settings to
>> the configuration file? This is complicated by the fact
that there
>> are multiple
>> formats for configuration files, each with its own
>> ConfigurationHandler. When a
>> component is configured, all it sees is a Map that contains settings--
it
> has
>> no idea what sort of file (if any) these settings came from.
>>
>> One idea that came up during a discussion with the IBM folks was
to
> somehow
>> connect a component to the ConfigurationHandler that was responsible
for
> its
>> settings -- then we can pass off the responsibility for storing
>> those settings
>> to that handler.
>>
>> -----
>>
>> A third issue, which is not necessarily required for the current
> scenario, is
>> how to change a configured components settings at run-time, and
savethose
> new
>> settings for later use.
>>
>> Could call getSettings(), change map, and call configure() again
with the
> new
>> settings. Or could be a separate method for changing (e.g.,
>> setSettings()), so
>> that the component can distinguish a full configuration from an
update.
>>
>>
>> Comments on any and all of these issues are welcomed.
>>
>> ...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
_______________________________________________
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
