Linux Registry, not only the issues side

["Avi Alkalay" <avi alkalay net>]

Was very nice to see KConfig high-speed performances.
I still didn't worked hard to improve algorithms, and I'm also paying the
price of making 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 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 unix sh
* 55-11-2132-2327
* 55-11-9659-9059 (mobile)

-- 
http://www.fastmail.fm - Email service worth paying for. Try it for free