[bt-devel] Config system

Eeli Kaikkonen eekaikko at mail.student.oulu.fi
Mon Feb 16 14:41:28 MST 2009


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: btconfig.tar.gz
Type: application/gzip
Size: 1148 bytes
Desc: not available
URL: <http://www.crosswire.org/pipermail/bt-devel/attachments/20090216/9e16ea1d/attachment.bin>


More information about the bt-devel mailing list