linux registry (no, not that again!)

[Avi Alkalay]

On Wed, 03 Nov 2004 20:13:16 -0500, Havoc Pennington <hp at redhat.com> wrote:
> Hi,
> 
> Here is a post of mine from a past thread:
> http://mail.gnome.org/archives/gconf-list/2004-April/msg00024.html
> 
> And what I would consider wrong with gconf:
> http://www.gnome.org/projects/gconf/plans.html
> 
> Like all "grand unification scheme" efforts, without consulting and
> listening to the major customers, success is unlikely. e.g. when Keith P
> succeeded with fontconfig, he talked to and then contributed patches to
> GTK, Mozilla, Qt, etc.

Thanks Havoc. I remember that kind message you sent, and just read it again.
The point is: much of the design principles of Elektra was discussed a
lot with the community, back in jan/feb/2004. Many things changed
based on that, and also based in the discussion in xdg in april. One
of them is the change notification need, specially for desktop apps.
It is now implemented.

About patches, we are making our best.....


One question: Is GConf planed one day to be a system-wide configuration store?



> For per-user config one set of issues is around group policy, directory
> services, and that kind of sysadmin-creates-user-profiles issue; the
> other set of issues has to do with how the desktop is implemented and
> what UI we want, for example you need change notification.
> 
> For system config the real issues of interest IMO are the overall
> management tools; things like cfengine, lcfg, oneSIS, or RHN.

Step by step. Configuration today is a huge problem. The UI
configuration tools are the last thing in the chain. Elektra is only
the base infrastructure for the storage, API and naming conventions.
After Elektra, comes an ecosystem of bindings, tools like regedit, app
adoption, and then higher level UI configuration tools. At this last
point, all the infrastructure for configuration will be already done
and clean.


> Another useful conceptual difference is between setting up a
> service/workload and associated data (e.g. configure apache, or
> stressing the analogy you could say that a user login session is a
> workload) and makework config such as telling the machine how to find
> its hardware (modprobe.conf type of stuff). The latter can/should be all
> automatic in an ideal world, though in a real world it can't be fully
> so.
> 
> You might think of the makework config as adjusting all machines to be
> the same, and the service config as defining a service that can then run
> on any of the identical machines.
> 
> User and system config can conceivably be addressed in the same library,
> as they share some core features, but I'm not convinced it has genuine
> value to keep them together.

I understand this points, but I think they are more related to the
semantics of the keys and values. I believe that if you put this
concepts in the bottom of the infrastructure (Elektra), you'll
optimize it for some apps, and deoptimize it to others. Thats why I
think they are needed, but in the next layer.
About this subject, I like to show this item of Doc Searls' monumental
World Of Ends: http://worldofends.com/#BM4


> Anyway. This is certainly an area where work is useful, but I think it's
> a long road that involves both listening and coding in order to get wide
> adoption.

Yep. And I'm glad we can discuss it here.

Your e-mails allways bring value to the discussion. So keep the stream.

Regards,
Avi