LinuxRegistry in Freedesktop & KDE

[Sean Middleditch]

On Fri, 2004-04-16 at 15:56, Avi Alkalay wrote:

> > 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.

Under what conditions?  When where these keys created?  Were you using a
real life file system and not ReiserFS which only a small handful of
users of this system would realistically have?  (Remember, we *aren't*
just for Linux!!)  Was the cache cold?

> 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.

Obviously you're incorrect, or we wouldn't be debating this with you... 
You are completely missing necessary functionality (and thus API), and
that's that.  Accept it or give up, because we aren't accepting any
configuration framework that doesn't support what *all* apps need.  And
the one file per key just *doesn't work* in real life, accept that. 
It's too hard to edit (I usually want to edit a lot of keys together,
what a PITA to do that your way), takes up too much disk space on real
life file systems, is too inefficient on real life file systems, etc.

> 
> All similar implementations we have today are or too desktopish (gconf,
> kconfig), or too bloated (based on SQL databases !!!!). The design

nothing about gconf is "desktopish."  I would *love* to have those
features in server apps.  Distributed servers would become easier,
configuration front ends would become easier, administration of user
services would be become easier, etc.  GConf is specifically written
such that it *can* run outside any desktop.

If you are still getting on about dependencies, then trust me, it's
perfectly possible to write a functionally equivalent (or functionally
superior) system without any of those; it'll just be more overall code. 
People use their dependencies for a reason, after all...

> addressed issues like to be usefull not only for desktop apps (think
> about fstab, inittab, XF86Config). I also decided to keep it VERY simple.

And thus it's too simple to work for most apps, desktop or not, given
that it otherwise offers no advantage to make it worth the recoding and
relearning.  End of story.

> 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.

No, that analogy is broken.  HTTP in TCP/IP makes no sense because most
TCP/IP traffic isn't HTTP.  Data types in the configuration system does
make sense because every piece of data/configuration has a type, be it
something generic like "string" or something app specific.  Putting the
datatype in the configuration files (or, perhaps more safely, in
separate schema files) allows automatic type checking which in turn
simplified the burden on application developers and graphical tool
writers.  Without them, the apps themselves have the verify/convert the
key values and do error reporting/analysis on incorrect formats/types,
config tool authors are forced to write either very ugly/generic tools
no better than a text editor or are forced to keep in sync with any and
all configuration changes made to the host app, with no easy way to look
up said changes except grep the source.

Again, there's a *reason* other configuration system store types.  You
haven't just stumbled across some unknown secret knowledge regarding the
design errors every config system designer before you has made.  Quite
the opposite...

> 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.

Oh come on.  The file backend has *nothing* to do with this.  The
problem is writing good UI and tools to modify the config files, not the
backend file format.  A small Perl script can read and edit pretty much
any config file in existence.  You're confusing what the block is on
making good quality config tools.

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

No, because they won't be sharing anything except the file backend, and
without *real* "infrastructure" (it's a stretch to try to call LR that)
the many weaknesses of LR will be made rather clear such as lack of race
handling/locking, lack of distributed storage, lack of change
notification, lack of data type checking, etc.  The two systems would
end up trampling all over each other.  They'd need a common daemon/layer
on top of LR.  Which then turns LR into nothing but a low-level
implementation of said daemon that can be swapped out any time the
developers feel like it.

Quit trying to work backwards, it doesn't work.  You keep trying to
claim that if you force LR into a system, all the apps will come to love
it.  Doesn't work that way.  The apps need to start using it first,
*then* it'll become a standard.  And apps aren't going to start using it
so long as its incapable of doing anything actually useful.

> 
> 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.

None of which you've managed to explain.

I'm starting to get the feeling you're not even listening... Probably
isn't worth "debating" any further if you don't start listening to *why*
we're rejecting LR and attempt to fix those issues.

btw, on a side note, if you want it to become a standard some day, you
should probably rename it.  FreeDesktop/KDE/GNOME all works on many
systems that are in no way, shape, or form Linux.  The name "registry"
often invokes a lot of emotional response from certain people who may
reject the project without even looking at the technical reasons it
should be rejected just because of the name.  ;-)

> 
> Regards,
> Avi
-- 
Sean Middleditch <elanthis at awesomeplay.com>
AwesomePlay Productions, Inc.