Linux Registry (from the author)

["Avi Alkalay" <avi unix sh>]

OK, let me comment some things here....

(Registry list users, please see entire discussion at
http://freedesktop.org/pipermail/xdg/2004-April/thread.html)



- Linux Registry is designed for system-wide usage. So it *MUST* be
simple. I started to design it as a sort of daemon, but I had to abandon
the idea because of early boot stage needs. A desktop system (mine is KDE
:-) is one of the possible users of it.





- Reading configurations is something simple: An app must read a value
for some "key". Putting additional logic to the configuration gathering
layer (relationship between keys, notification, etc) may be usefull, but
it looks for me as implementing HTTP inside the TCP/IP protocol. TCP/IP
is good and **widely** used because it is simple and "does-only-that". If
you need additional functionality you'll have to stack it, and suffer the
specialization consequences.





- Regarding speed and efficiency, I have to say that I can read and
qsort() more then 1000 keys from a not-tunned ext3 FS in my IDE-powered
laptop in few milliseconds. Please try it first before saying it is
inefficient. This was one of my major concerns. Also, looking at GConf's
XML files, do you know how much time __AND MEMORY__ you need to link your
XML and corba (!!?!?) libs (OK, it is done only once), read the XML files
(OK, this can be fast), XML-parse, maybe sort, and deliver to the app??
Well, I have no idea, but I bet it will take more time then reading small
plain files using low level filesystem speed. I'd like to see banchmarks
for 1000 keys and compare with the Registry, which BTW I didn't worked
hard in algorithm improvement.





- What about changing a key? I guess that when you want to change only 1
key in a hundred-keys file, you'll have to parse all the XML tree, change
that little one, and rewrite it all again. Is that true?





- Thinking system-wide, how security is handled by GConf? How can a
daemon (that runs as some user process) can differentiate access to
different keys based on who connected to it? How does it knows who
connected? Do you guys think about security inside a namespace or each
user has its own daemon? If so, isn't it a waste of memory (wich is much
smaller then HD storage)? And if it handles access permissions, as a
daemon, isn't it a reimplementation of the OS security layer? Is it as
reliable as the OS? Doesn't it waste CPU time to do that? Let me tell you
that the Linux Registry doesn't waste 1/2 CPU cicle to handle security.
It is all done by the underlying OS, which is reliable and fast and
already-bug-free as we know. The key file will even deny to be opened if
the user doesn't have permission to do it.





My motivation to write the registry was because Linux/Unix needed one. I
hate to reinvent the wheel, and trust me, I know the wheels available.
Reinventing is a terrible problem in the OSS space.
When I designed it, I tryied to address all cited requirements. And yes,
I started as a daemon until I saw it was bad business. Yes, it started as
a Berkeley DB database file, until I realized it was too blackbox. Yes, I
wished it could be stored as XML. Yes, I didn't liked the idea of 1 file
per key, until I realized this was the unique and right way to do it (and
not big deal after all).


(this is a desktop list, so...) The desktop is nothing if the user
doesn't have control of (or knowledge to control) system things like
mount points, automatic software and HW driver installation, etc.
The Registry is a framework to build higher level super-consistent GUI
for system administration.

The biggest the problem, the simplest will be the solution. This is
nature's law.
Unix configuration is a nightmare of a problem. Linux Registry is simple
enough.


I'd like to see (good and bad) comments to this. Most of Registry's
desing was based on this kind of discussions at places like orkut.com.
I'm allways learning.


Thank you !!
Avi

-- 
http://www.fastmail.fm - Faster than the air-speed velocity of an
                          unladen european swallow