Status of gconf -> dconf

[Simo Sorce]

On Tue, 2009-02-24 at 08:12 -0500, seth vidal wrote:
> On Tue, 2009-02-24 at 10:43 +0000, Bastien Nocera wrote:
> 
> > For GConf, we were human editable and readable through gconf-editor, and
> > greppable/diffable through gconftool-2.
> > 
> > Either you're fueling a flamefest, or you don't understand what's
> > required for a modern configuration system.
> 
> I'm not trying to fuel a flamefest, but it does seem apparent that you
> do not understand the requirements of a modern network and shared
> resource system.
> 
> If you want to know what things are common problems with a linux desktop
> infrastructure in a shared resource environment ask on the list. There
> are a good number of folks here who have to maintain resources for
> hundreds of users, not just single users on a desktop/laptop.

Seth, the fact that sqlite or other db-style files have problems on some
networked filesystem either indicate a bug in the db or in such
filesystems.

NFS(v2/3) is known to be a bad file system, sure it "mostly" works for
users, but has so many problems I do not even care to think anymore
(riduculous locking, stateless, no decent client caching ...).

NFSv4 and CIFS should be much better, is sqlite breaks on these
filesystems there are perhaps bugs in their client kernel components.

It would be better to fix the FSs rather then just ditch the problem
completely.

That said, given home directories must stay on a trusted server anyway,
building a central daemon that the networked desktops can use instead of
trying to open databases over networked filesystems (performance sucks
when opened from multiple clients) is also a good idea.

As for files Callum,
they are fine for manually managed machines, where you have a tiny
number of daemons that rarely change their configuration, and when it
happens usually are restarted.

For any application that have frequent automated configuration changes
(ie through an internal API), that need to share configuration options
with multiple applications, or that store complex data, a file is not
only *not* useful, it is really an impediment.
The only files that are well structured enough to not be an impediment
are XML files, and most people that claim text files are the solution of
all problems also claim XML is not a format to use.
And XML files are still not really good for the desktop, they lack the
features a daemon with a database/directory like backend can much more
easily offer, like notification of changes, not to think of ACLs per
attribute, etc...

Quite static applications are ok with text file (to a degree, some ).
But dynamic applications like those running on a desktop have a much
harder life trying to use text files.

I understand that some people had traumatic experiences with windows and
registry files, but a single bad implementation shouldn't be used as an
example to banish everything good there is in a registry/directory like
approach.

As for editing/grepping/etc.. unless you want also to impose the
restriction that you have to use "vim file" then most decent system have
CLI tools that allow you to edit/search within the store, so your litmus
test of being readable by humans and searchable is certainly not a
problem.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York