On Wed, 03 Nov 2004 20:13:16 -0500, Havoc Pennington <hp(a)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