| Re: [higgins-dev] Dynamic setting updates for IContexts |
both good points that I have no comeback for.
Ok, so let's go back to choosing between these:
IContext.setComponentSetting(String name, Object value);
IConfigurableComponent.setComponentSetting(String name, Object value);
For now, I'll do the former and if Mike or someone wants to talk about the latter, we can switch over later.
Jim
>>> "Duane Buss" <dbuss@xxxxxxxxxx> 06/25/08 10:54 AM >>>
Two Issues
* How do I know if the context attribute is temporary or permanent, and is this a per instance attribute or a global setting that other instances of this same context will pickup.
* Doesn't this create confusion between config settings and context properties? How many items in config would also be settable via setProperties?
Duane
>>>
|
From: |
"Jim Sermersheim" <jimse@xxxxxxxxxx> |
|
To: |
Higgins dev <higgins-dev@xxxxxxxxxxx> |
|
Date: |
06/25/08 10:36 AM |
|
Subject: |
[higgins-dev] Dynamic setting updates for IContexts |
Over the past month, we've had a number of requests to be able to programatically update different settings for an instance of IContext. The use cases typically are for things where we need the context provider to behave differently based on changing conditions.
At first, we started thinking we should piggyback the existing IConfigurableComponent interfaces. Currently IContext does not extend IConfigurableComponent, but we could change that. Two problems exist with doing it this way:
* There's no way to update a single/specific setting. It would be cumbersome or even break things to send in an entire new configuration Map each time we want to change a single setting
* Often the component settings are shared among other components. The ability to update that shared Map may cause other problems.
So next, we started thinking we need a simple way to update IContext instance-specific settings. The idea was to add something like IContext.setProperty(String propName, Object propVal); One could call it like this:
myContext.setProperty("UseSSL", "true");
There are some questions like: What if the CP doesn't support the "UseSSL" setting? Should it fail the call to setProperty? How does the caller discover ahead of time whether a CP supports a setting?
I started looking at that and thought, wait a minute, IContexts *already have* properties. They're called attributes. All a cp needs to do is we need is to define special attribute identifiers which are valid to be placed on their context, and have a defined semantic behavior. So one could make the same setting call like this:
myContext.addAttribute(new BasicAttribute("http://example.com/ontology/contextSettings#UseSSL", "true"));
The benefits are that we introduce no new APIs, and the caller can discover whether the context's model allows specific settings
Jim