D-Conf

[P. Kaluza]

Hi Avery,

Avery Pennarun wrote:

>These problems are not going to go anywhere fast, so I'd like to officially
>drop UniConf from this particular race - the race for being the "standard
>Unix configuration system" API.
>  
>
Ok, noted.

>Elektra is continually criticized for its one-key-per-file storage system,
>but this is a total red herring.  It has pluggable backends.  The default
>system is super-easy to implement and uses kernel-level security, so it
>*will* be secure and easy to use, without a tonne of code.  And it has a
>UniConf backend, in case you need more power.  (Yes, I know you didn't want
>any arguments related to stackability.  But stackability is a huge benefit
>of standardizing on one config system, so we might as well take advantage of
>it!)
>  
>
I agree that pluggable backends will be useful for any system we might 
adopt. But people won't like to _depend_ on stackability, that's why i 
tried to discourage this line of argumentation: "UniConf already has an 
LDAP backend, so by extension, so has Elektra" - which really wouldn't 
be true considering you'd have to convince the user to not care for the 
overhead and additional installation complexity. The stacking is 
transparent to the code developer but not to the end user/admin. If you 
don't care, that's fine. Let's just be careful to not advertise more 
features that we have.

>>As far as I know. At this moment is GConf the only system of these three
>>that has a wide userbase. My opinion is that this fact can play an
>>important role when the migrating-part starts.
>>    
>>
>
>Definitely true, except that it pretty much has to be rewritten from scratch
>in order to become cross-desktop.
>
If you have to completely rewrite something to replace one IPC mechanism 
with another, at least one of your IPC mechanisms would be rather 
broken. But I don't think this would be the case for GConf.

>Never mind that it currently has more giant dependencies than UniConf, and I'm embarrassed enough about UniConf :)
>  
>
$ apt-cache show libgconf2-4
Package: libgconf2-4
[...]
Version: 2.8.1-4
Replaces: libgconf2-2 (= 1.1.7-1)
Depends: libc6 (>= 2.3.2.ds1-4), libglib2.0-0 (>= 2.4.7), liborbit2 (>= 
1:2.10.0), gconf2 (>= 2.8.1-4)
[...]

that doesn't look too unsensible.

$ apt-cache show gconf2
Package: gconf2
[...]
Version: 2.8.1-4
Replaces: libgconf2-4 (<< 1.1.10-2)
Depends: libatk1.0-0 (>= 1.7.2), libc6 (>= 2.3.2.ds1-4), libgconf2-4 (>= 
2.8.1), libglib2.0-0 (>= 2.4.7), libgtk2.0-0 (>= 2.4.4), liborbit2 (>= 
1:2.10.0), libpango1.0-0 (>= 1.6.0), libpopt0 (>= 1.7), libxml2 (>= 
2.6.11), zlib1g (>= 1:1.2.1)
[...]

this is certainly worse, but the graphical stuff is for the "gconf 
tools" in that package, as

$ ldd /usr/lib/gconf2/gconfd-2
                libgconf-2.so.4 => /usr/lib/libgconf-2.so.4 (0x40024000)
        libORBit-2.so.0 => /usr/lib/libORBit-2.so.0 (0x4004f000)
        libpopt.so.0 => /lib/libpopt.so.0 (0x4009f000)
        libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x400a7000)
        libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x400db000)
        libdl.so.2 => /lib/tls/libdl.so.2 (0x400df000)
        libgthread-2.0.so.0 => /usr/lib/libgthread-2.0.so.0 (0x400e2000)
        libpthread.so.0 => /lib/tls/libpthread.so.0 (0x400e7000)
        libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x400f7000)
        libc.so.6 => /lib/tls/libc.so.6 (0x40177000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
shows. This are still quite some dependencies, but not unreasonable for 
a G-world originated system. The question is, can we trim this down if 
we decide to choose the gconf architecture.

>Note that D-BUS is still intra-computer only (that is, it doesn't use the
>network).  I don't see why nobody has extended it to network awareness yet,
>since it looks like it would be easy, sensible, and reliable, but they
>haven't.
>
I think it's a safe bet to say that, by the time it hits 1.0, D-Bus will 
have network transparency.

>I would rephrase your requirements a bit:
>
> - it must have events/triggers/notifications of some sort, yes.
>  
>
ACK.

> - it should *allow* binary data, and *allow* documenting keys.
>  
>
i'd say "strongly encourage documenting keys".

>  - it should *allow* a network-transparent protocol to be implemented,
>   but that should be invisible to the API.  The basic implementation
>   should be tiny and not *require* this feature to be done.
>   
> - it shouldn't *require* a configuration daemon, but could allow one
>   if that makes sense.
>  
>
No, for Desktop environments I think it's better to require a daemon. 
See below.

> - it should *allow* a central configuration repository with
>   default/current/override settings.
>  
>
Yup, allowing for multi-level configuration from day one will certainly 
help acceptance. (I envisioned Schema Defaults/Distributor/ Site 
admin/Computer admin/User, with Distributor, Site admin and Computer 
admin having the ability to "lock down" certain keys.)

On Daemons:
I can understand why for the "System scope" you'd not necessarily want 
to involve a daemon - boot-time complication and security questions come 
to mind. However, when talking about a desktop system, you really really 
want to require a daemon, because otherwise any instant-apply semantic 
completely breaks (you can't do iNotify tricks when the home directory 
is NFS-mounted). Also, current desktop apps are really large enough 
already, without loading one to two backends into each process. So I'd 
even recommend against a "fallback backend" in the library.

>Elektra meets all of these requirements.  GConf-rewritten-to-use-DBUS, if it
>existed, would as well, except that it would probably *require* a
>configuration daemon because DBus just does.  Luckily, though, DBus is small
>and simple, so this daemon wouldn't be overweight.
>  
>
ACK.

>Right.  This is why you should aim for a *tiny* system with maximum
>*flexibility* in adding *optional* backends.  To me, that's either Elektra
>(exists) or rewritten-GConf (doesn't exist).
>
>You can see my obvious bias toward code that already exists instead of code
>that doesn't.  Of course, the other side the argument is which one is more
>*popular* right now, and GConf is clearly winning there.
>  
>
While I don't have this bias myself (I'd rather "get the API right once 
and for all") you convinced me to have a closer look at the existing 
Elektra codebase.

Have fun,
  Philipp