LinuxRegistry in Freedesktop & KDE

[Sean Middleditch]

On Fri, 2004-04-16 at 13:46, Duncan Mac-Vicar Prett wrote:
> El Friday 16 April 2004 10:33, Sean Middleditch escribió:
> > A system with the features of GConf *could* be developed for small
> > systems.  Or maybe just designed to be much less desktop-specific.  A
> > configuration system that is only good for a small number of apps (like
> > Linux Registry) really isn't worth much, tho.  If you want a
> > configuration system to be "standard", it needs to support all
> > applications.
> 
> I never suggested to put LinuxRegistry as-is. You can implement features as 
> change notifications, either in a small daemon, or via some kind of callbacks 
> using fam in the api itself, maintaining the almost no dependencies goodness.
> But th advantage is that apps whose don't need notifications, or whose don't 
> want to use right now, still can access the configuration in a easy and 
> direct way.

And then as soon as the needs changes, boom, everything breaks, because
teh apps are talking to two different layers of an API.  If you want a
standard config system, all apps need to use the same API.  Leave the
"does it have a daemon" in there as a tunable implementation detail if
you.  The point is that if you said "these daemons only support the
basic API" then as soon as you need the "heavy" features you need to
recode.  Going the other way around, if all the daemons spoke to an API
that supported change notification, lock down, defaults, etc., then you
can just swap the underlying library out to a liter version for free. 
Change notifications would simply never be delivered, for example, and
so on.

Which then, again, turns Linux Registry into nothing but a file store,
which is useless.  The library/API you coded to should handle its own
file store, because the library is better suited to know what it needs. 
(A database?  LDAP?  whatever.)  One version of said library might use
Linux Registry, but Linux Registry would not be a requirement of the
API, as it would boil down to implementation detail that the application
authors do not in any way want or need to care about.

You've found Linux Registry, a solution, and are trying to find problems
for it to fix (/etc).  You're doing this backwards.  Start looking at
the actual applications (desktop or server) and see what features they
want.  Then design a framework/API to support this.  Then do the
implementation details however you feel like.  (And, personally, if you
do, avoid Linux Registry's implementation, because it's god awful
wasteful of disk space on most file systems and quite inefficient on all
of them.)
-- 
Sean Middleditch <elanthis at awesomeplay.com>
AwesomePlay Productions, Inc.