Re: [higgins-dev] Dynamic setting updates for IContexts

[Greg Byrd <gbyrd@xxxxxxxx>]

For the second option (IConfigurableComponent.setComponentSetting), I assume
this would replace a component setting that was already there.  So we'd need
a getComponentSetting() for the case in which you just want to change an element
of a setting(e.g., add new element to list or map, remove element from list/map).

IMO, this would only affect the instance of the component being modified.

And, of course, this might trigger other actions in the general case, 
essentially a re-configuration of the component.  For some components, the 
setComponentSetting method could be quite complex, as the action could depend on 
the particular setting being modified.

...Greg


Jim Sermersheim wrote:
> 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
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> higgins-dev mailing list
> higgins-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/higgins-dev