[bt-devel] Config system

[Martin Gruner]

Hi Eeli.

I just reviewed your proposal for the config changes at 
http://devel.bibletime.info/wiki/Reworking_the_Configuration_System.

I don't have strong feelings about our current system, so feel free to change 
it. But I have several aspects that should be taken care of.

-Unifying CResmgr and CBtConfig in a new system is great, but CProfile works 
well and should not be changed now just for the sake of changing it. Please 
leave it as it is, we can take that step later on.
-adding a Signal/Slot mechanism to the config seems to be a great enhancement 
for me.
-If we drop the compile-time checking for settings names, we should have a 
runtime check that causes BT to crash when trying to access an unknown setting 
(an assert). That should prevent spelling mistakes.
-The new and old systems cannot really coexist. It needs to be a replacement, 
and that must make sure all of the user's (important) settings are migrated, 
if you have to change the format. We already have a small framework for 
upgrades like this.
-Using QVariant, does that mean that I need to cast the values wherever I want 
to use them? Maybe you want to provide some convenience wrappers that do the 
conversion already, like value() (Variant), intValue() (int), stringValue() 
(QString) and so forth. What do you think?

Now, given that this means quite some work (=time), and has to be complete to 
be releaseable, I'm not sure if it would be the right time now to work on 
this, but I cannot decide this for you.
How about creating a branch for this change that allows you and others to 
collaborate in SVN? Whenever things are near complete, we can merge this 
branch. But note that the longer it remains open, the more difficult the merge 
will be.

Right now I think that it would be better to work on the Qt port instead. This 
would allow me and others to start working on releases for different platforms, 
while you keep working on the inner refactorings. Just a suggestion, that also 
depends on how much time you will have.

Gary, I'm be very interested in your opinion as a Qt professional regarding 
Eeli's and my suggestions.

God bless,

mg


On Monday 16 February 2009 22:41:28 Eeli Kaikkonen wrote:
> Eeli Kaikkonen wrote:
> > At the same time I have planned a new config system. I'll try to
> > implement it so that it can be used for creating the actions without
> > messing up the old system. Then people can see if it's good or not.
>
> Here is a draft attached. It's not complete or functional yet. It's
> undocumented on purpose: if you can easily understand how it works, it's
> easy to use.
>
>
> Pros:
> 	- very simple public interface, easy to use
> 	- it's simple to add a new config item (vs. the old system which 	  is
> incomprehensibly difficult)
> 	- const values and mutable settings with the same interface
> 	  (vs. the old system which has CResMgr and CBTConfig)
> 	- string keys can be passed as arguments (namespaces can't which
> 	  is a huge disadvantage in the current system)
>
> Cons:
> 	- uses runtime memory to store key names (namespaces in the old
> 	  system don't take space)
> 	- adds some runtime speed penalty
> 	- no compile time checks
>
> Answers to cons:
>
> Memory consumption is not a problem. Any module takes much much much
> more memory. The old system uses runtime memory, too, though maybe a
> little bit less.
>
> Runtime speed is not a problem. Graphical UI is much more costly, not
> speaking of html rendering. If a setting is used more than once in one
> place it can be put to a local variable instead of calling BtConfig::get().
>
> Compile time check has some value. However, as far as I know there
> exists no system which has good sides of both: compile time check and
> runtime simplicity. The current system has lost simplicity and gained
> little. The new BtConfig is between the two: it has strict runtime
> checks hidden in the implementation but very simple public interface.
>
> You can use a key only if it has been set in init phase - this prevents
> accidental typing errors if the code is ever tested even once. Every key
> must have an explicit default value. The value can be set only with the
> correct type even though QVariant itself is not strict about types.
> Faulty type is also caught runtime if the code is tested even once.
>
> As I said, this hasn't been tested. I may have missed even something
> obvious. Feedback is needed.
>
> --Eeli Kaikkonen