Linux Registry, not only the issues side

[Avi Alkalay]

Was very nice to see KConfig high-speed performances.
I still didn't worked hard to improve LR's algorithms, and this is also
the price I pay to make LR thread safe. But it will never be so fast as 1
file with many keys as KConfig's. But KConfig is KDE only, not system
wide.

I still would like to see GConf's numbers. XML is a different.
Are this discussion's e-mails being accepted in GConf list?

Anyway, I changed that paragraph about ReiserFS, putting this in place:


""""""""
Some may think that one file per key will consume many filesystem
i-nodes. Actually, when not using Reiser4 filesystem, it may consume some
more disk space, and it may also be not so efficient than reading one
single text file, as KConfig does. But Registry's nature let applications
load their keys on demand; so it is possible to avoid the
read-all-use-some approach. Writing updated keys back to disk is also
more robust, because unchanged keys won't be touched, different from a
single file approach, that must be entirelly rewritten.


Besides that, big applications (like Mozilla, Konqueror, KDE, Gnome) key
gathering time is a very small part of what they have to do to start up.
And the benefits of an homogeneous registry to all system are much bigger
then these issues. Think about a common integration between everything,
flexibility, security granularity and openness.
""""""""

It is here: http://registry.sourceforge.net/#keystor

Regards,
Avi

-- 
Avi Alkalay
SW & IT Architect :: Linux, Open Standards
 
Linux Impact Team :: ibm.com/linux
* avi at unix.sh
* 55-11-2132-2327
* 55-11-9659-9059 (mobile)

-- 
http://www.fastmail.fm - Sent 0.000002 seconds ago