| [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