Dynamic configuration information

Question

I can call getConfigDescriptionRegistry.getConfigDescriptions or one of the other methods to get the configuration descriptions for an thing-type. If I wanted to modify these at runtime, and provide my own configuration provider, can I do this? I'm not sure what happens deeper in the system - I assume that only 1 provider can respond to any uri? Or maybe not - if so, how is this managed?
I have two needs -:
1) To be able to add some configuration options into a parameters [options] array. These are only derived at runtime and are system/network dependant, so can't go in the XML.
2) To be able to add additional parameters to the configuration. Again, these are derived at runtime depending on how a device is configured (for example).
I can easily create my own provider and completely avoid using the XML provider, but I'd kind of like to be able to lever off the existing infrastructure and just add to/modify the static configuration rather than have to reimplement everything...
I guess I could (probably!?!) use getConfigDescriptionRegistry.getConfigDescriptions to get the static data, and then create my own provider that appends my data and modified the data that needs to be changed? I would guess it needs a different uri, although I suspect that this might then break something else when the system tries to link thing-types to the configuration provider? This seems a little messy though so maybe there's a better way?
Are there any pointers on how this might be achieved? I'm thinking it might be easier to do it all in my own config provider which is what I'm currently doing (mostly for test and concepts), but I want to work out the best way for a the final implementation...
Cheers
Chris

Answer 1

Kai Kreuzer wrote on Wed, 22 July 2015 10:44
Which leaves us with Chris' problem that he would like to offer options specific to a certain device at a specific moment. The use case with the WLAN SSIDs is actually also such a case, so I guess sooner or later we need to address this.
Where do we go with this one? It's my next target to hit
So, if we don't want to link this to things (and I totally agree with the rationale), then we need an alternative. Currently, we have configDescriptions to describe the configuration options, but the 'other side' of the interface (the actual setting of the config) is done differently for different classes (I think that's true). For example, in the thingHandler, we have the handleConfigurationUpdate method - maybe in the channelHandler there's a similar method (I've not checked) - I don't know what other classes use the configDescriptions (rules I think?) but I guess every implementation is different?
Why aren't there standard interfaces for handling the various configuration related functions. We could have had (eg) ...
// Handle the updates of any configuration
interface ConfigConsumer() {
void handleConfigurationUpdate(Map<String, Object>);
// Handle dynamic configuration updates
interface ConfigDescriptionUpdate() {
List<ParameterOption> getOptions(String parameterId, Locale locale);
A thingHandler, or ruleHandler, or whatever wants to implement configuration implements these interfaces. Then, all configuration, both description, dynamic changes, and handling of changes, could all go through a central provider (and even REST interface!).
As far as implementation (and looking specifically at things here - other implementations would be similar): For registration, when the thingHandler is created, a check could be made to see if it implements this/these interfaces, then to register this handler with the configDescriptionProvider (along with it's UID). When the config descriptions are updated, the configDescriptionRegistry can request the updates from the handler if there's one registered.
One thing I'm unsure of here is the use of the UID. For things/channels etc, it seems a good idea to include the thingUID as it makes it a simple lookup in the configProvider (and if you didn't use the thingUID, I'm not sure how you'd link it). However, will all implementations of configDescriptions have a UID - eg I think I read rules will use the same config services - will they have a UID?
I realise I've probably confused matters by suggesting a common interface for handling of config changes as well as just covering the issue at hand, but I thought I'd mention it since it does in some ways seem a shame to have a common config description provider, but no common way of handling configuration updates/changes etc... Anyway, I hope that didn't confuse matters (too much!) - we could ignore the handleConfigurationUpdate side, and just look at the ConfigDescriptionUpdate, which is the current issue at hand...
What do you think? I've not thought this through in massive detail, but if you think this is workable, I'd be happy to look at the ConfigDescriptionUpdate impementation further...
Chris