Re: LinuxRegistry in Freedesktop & KDE

["Avi Alkalay" <avi unix sh>]

I received a lot of comments from folks on this lists. Thank you all for
the comments.
Please join the discussion list at
http://lists.sourceforge.net/lists/listinfo/registry-list

> > Searching for more technologies, made me land at  the Linux Registry
> > project (http://registry.sf.net), by IBM employee Avi Alkalay.
> >
> > I wonder why never heard of it before. 
> 
> Because nobody uses it ;-)

The Registry is a pretty new project. I started it last november, and now
it is stable and very usable. There is some new cosmetics I'll implement
next weeks. But most of it is already there.


> It's an interesting concept but I'm a bit worried about the performance. 
> Accessing single keys will probably be quite fast, but if you need to
> read a lot of them, then it might become slow (N system calls per entry)

When you need to read a lot of keys (most apps will read many of them),
you'll use registryGetChildKeys(), which are optimized for that. I can
read AND _sort_ more then 1000 keys in few milliseconds. I don't have the
number right now. But remember, this is pure C "-O3" fast code.


Regarding other comments, I'd like to tell you guys that I spent a lot of
time architecting and discussing with Linux folks the design of the
registry. Aspects like Berkeley DB, XML or flat files; library or
service; 1 file per key or 1 file per group of keys; etc. What we have
now is the best balance of acceptance, functionality, performance,
simplicity, and clean API.

All similar implementations we have today are or too desktopish (gconf,
kconfig), or too bloated (based on SQL databases !!!!). The design
addressed issues like to be usefull not only for desktop apps (think
about fstab, inittab, XF86Config). I also decided to keep it VERY simple.
So the registry knows nothing about data semantics. This gave me many
performance benefits, and simplicity. This really makes sence. Thinking
in the oposite way is like to implement the HTTP protocol into TCP/IP,
which makes no sence.


> [1] It would mostly [2] be a matter of reimplementing 
> KConfigBase::lookupData() and KConfigBase::putData()
> [2] The other 90% of the work will be to reimplement the other virtual 
> functions, such as entryMap() and groupList()
> [3] I'm more than happy to assist you with adapting KConfig in the 
> meantime 
> though.

To see the registry as the backend of KConfig is interesting, but we'll
see the REAL benefits of it when it will substitute /etc files. I can see
many linuxconf-like apps appearing, but that can handle configurations in
a MUCH more consistent way, and then finaly the Open Source process will
choose one as THE one.

And of course, to have KConfig and GConf share the same configuration
infrastructure will bring to user many automatic-software-integration
benefits.

Some registry-like software (mine or other) is inevitable. Traditional
Unix guys must put their old paradigms down. A system-wide registry-like
software only have benefits.

Regards,
Avi

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