Status of gconf -> dconf

[seth vidal]

On Tue, 2009-02-24 at 09:08 -0500, Simo Sorce wrote:
> > Why, exactly? After all, your XML data has to live somewhere, and I'd
> > guess it will be a file at the end of the day. So how is setting a value
> > in an XML structure fundamentally different from writing that value to a file?
> 
> If you have to ask this question it means you never tried changing
> configuration files from an application (or did a sloppy hack that
> *mostly* works).


Okay, let's stop it with remarks like the "if you have to ask then you
don't understand".

We can all play this game, if you want, but it's not a good way of going
about interaction. It's elitist and dismissive.

If you have situations where changing config files breaks down - then
please, explain them. Let us understand the problem. B/c Istr having
config files change quite commonly from applications from about
1999->2002 on shared filesystems and not having the whole world explode.



> Except that:
> - filesystems are not meant to hold huge numbers of small configuration
> files, most FSs have limits on the number of inodes, have inodes of 4KiB
> in size, so storing a a couple hundreds byts in a file is a total waste


By your own previous argument, then let's fix the filesystems. And,
quite frankly, I think the above concern is going away in the face of
filesystems like ext4, btrfs, etc.

> - notification does not come for free, there are limits for inotify and
> abusing them is not a good idea

what are the cases where notification is required?

> - ACLs are available only for users known to the underlying unix system
> *when* available, and they are not standard: posix ACLs, NFSv4 ACLs, AFS
> ACLs, NTFS ACLs ....

This sounds like an argument for putting things in a file and having a
common base acl for them.

> - Unix filesystem ACLs usually have no concept of things like roles an
> app may have, can't be set as it would be useful from a user app (only
> root can easily change ownerships and permissions at will), and are
> quite restrained in what they allow: read, write, execute, which is
> often not enough even for files. 

What's the use case for a user needing to change the ownership of
his/her own files for configuring an application?

-sv