Ivesvdf/Bacsy — Issue #85: Sources should have a way to change their "configuration" at runtime
Author: nathansamson
Created: 2012-02-18 23:12:59+00:00
State: open

This is useful for UI applications that want to change things like enabled, priority and so forth.

This is quite trivial to implement in Bacsy/Client/Source.{cpp,h} for most things but for two exceptions (ExecuteAt and Name).
But the problem with this approach is that things will not change in the configuration, so when the application restarts all changes will be lost.

Solution A to this problem would be to have the UI change the Configuration itself. Obvious disadvantage is that the UI has to do two calls + keep itself a link between the configuration and the source.
But It is the simplest solution for the bacsy library itself. Also in this case we don't have any problems with read only configurations.

Solution B could be to propagate this changes from the Source to the ISourceConfiguraiton. But this causes problems for read only configurations. What to do in the case the configuration is readonly, should we throw an exception in the Setter function or not.

Solution C could be to propagate the changes from the configuratiuon to the source. This solves the problem of read only configurations (they will not have the setter functions or the configuration throws exceptions which is transparent). It also solves the theoretical case where configurations can change outside the UI application / Bacsy library (not so theoretical after all, dconf/gconf work this way).
On the other hand this seems to be a little bit counter intuitive. Also one could ask if we want to make it possible to change the sources state without changing the configuration (For example temporarily disable a source, but not saving it).
Also we have to keep a connection in the configuration to the source.

PS: Why I was saying that Name and ExecuteAt are harder to change than the rest:

Name: Names should be unique for the moment (although this seems to be an implementation detail of the configuration backend), so changing them needs to check if the name is indeed unique (and as such can fail).

ExecuteAt: this needs to change the timers (not that hard probably, but harder than just changing a member variable).