Re: LinuxRegistry in Freedesktop & KDE



Am Freitag, 16. April 2004 08:36 schrieb Duncan Mac-Vicar Prett:

> Searching for more technologies, made me land at  the Linux Registry
> project (http://registry.sf.net), by IBM employee Avi Alkalay.

The reasons stated why we need some common access method are all very valid I 
think. Unfortunately it may not work out to have everybody change to the same 
type of registry-type storage, API etc..., it might not even be desireable 
after all.

The "key-value" middlelayer[1] above the traditional /etc files (or other 
backends (reiser4, interactive config server, or whatever)) can bring the 
same benefits. The applications you want to configure may choose the backend 
that fits their need best (say interactive gconf), they don't have to relay 
on the middlelayer. However you could still configure this application 
through the middlelayer. This allows smooth transitions between backends.

    "Using the Registry, configuration file's syntax and handling
     will not be a rework for each software."

I think this is adressing the fact that it is hard for config tools to track 
format and option changes. But wouldn each applications need to be changed 
and limit itself to only use the registry API?

The idea of CFG to address this is to have meta-config-definitions that are 
maintainable separately from CFG. That way the system is easy to update by 
meta-config-definitions that can even be distributed with the application 
itself.

Another feature of the meta-config definiton is that it can define more than 
just keys and value- types, -choices and -relationships. Applications 
maintaining their own meta-config definitions get the benefit to easily have 
a more better graphical configuration tool. It is possible to define forms 
and wizard-logic for their config options. Frondends use those to provide 
customized user interfaces beyond keys and values.

Cheers,
Christian


[1]
http://freedesktop.org/Software/CFG

Actually, KDEs KConfig XT seems to have some similarity, even though IIRC it 
genrates source code from xml meta-definitions instead of a run-time 
representation.








[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]