D-Conf

[Avery Pennarun]

On Fri, Mar 04, 2005 at 02:06:17PM -0500, Sean Middleditch wrote:

> > You're arguing against something that is no work.  The only unusual
> 
> The below are definitely things that involve a lot of work.  ;-)

I continue to disagree, and you have not demonstrated otherwise.

> > requirements for an early boot config system are:
> > 
> >  - doesn't require a daemon
> 
> This requires that the library be capable of accessing the config store.
> This means that developing the library is harder, the library is bigger,
> and that the library requires more maintenance.  It can also adversely
> affect the API of the library, as it can no longer be a wrapper around a
> simple message interface (i.e. D-BUS).  The same arguments that apply to
> using threads/daemon in D-VFS (slow NFS shares, for example) apply here
> as well.

What I said is this: elektra and gconf *already* don't require a daemon. 
Are you going to force the maintainers to *remove* this feature?  If not, we
don't need to argue about it (and it's no extra work).

> >  - doesn't have a lot of weird dependencies because /usr might not be
> >    mounted.
> 
> So, in order to make the library usable at early bootup, you'll
> effectively force yourself to write lots of code that you could
> otherwise just reuse from glib or the STL or whatever is appropriate?

glib is not a particularly weird dependency, so I wouldn't object to that. 
CORBA bad, WvStreams bad, STL bad.  All of those things have the tendency to
explode when you upgrade your system.

But note that dbus was specifically written with this requirement in mind,
and it works fine.  (It theoretically doesn't require glib, but it does
require a mainloop, and glib is the most sensible one to use.  The code has
been carefully segmented in case you want a different mainloop.)

gconf-for-dbus, I'm pretty sure, depends only on glib and dbus.  Elektra
depends on neither, and the code is really *not* very complex.

So there's no work required here either.  Why should we argue about it? 
Code already exists that satisfies this requirement and it doesn't hurt
anyone.

> The use cases, required features, expected behavior, and acceptable
> limitations between a system used for early bootup configuration and
> desktop configuration are completely different.  The kinds of APIs you
> expect to have available are different; early bootup doesn't even need
> to change configuration and wants a simple synchronous read method,
> while desktop apps need to change configuration with rollback and
> transactions and want notifications of changed configurations during
> runtime.  These are completely different systems - there's no reason to
> try to make one code-base do both.

The company I co-founded has sold thousands of servers, all of them running
UniConf, that seems to prove you wrong on all of these points.  I know that
it's bad form to appeal to my job title and claimed expertise, but trust me
- all of these features *are* useful for early bootup and system-level
stuff.  They really make a difference.  In fact, they make the difference
between whether a complex Linux server (not an appliance) is usable by a
newbie and as easy-to-use and reliable as Windows - or not.

I don't actually care whether D-Conf is going to be designed to support
system-level stuff or not; UniConf will just include it anyway and use it
where it makes sense.  What I'm saying is that I know this problem space
inside out, and whether you like it or not, both Elektra and gconf-for-dbus
*already* have everything they need to support system-level configuration.

You're just trying to remove requirements for features that already exist
and weren't much work to implement.  It would be a shame to advertise
gconf-for-dbus, or elektra, as niche configuration systems when I know for
sure that they can configure all sorts of things outside the desktop.

> Again - WHY do you want pluggable backends in the first place?  Just
> because they CAN be done, and just because you can create a theoretical
> person with a theoretical reason to maybe possibly want a different
> backend, doesn't really help here.  What is an actual, concrete,
> real-life use case for using a backend different than the default?  The
> default backend should support every feature that the system is capable
> of, should be stable and efficient enough for all needs, etc. - if it
> isn't, the right solution is not to make the backends pluggable, but to
> just fix the default to be good enough.

This is a loaded question.  Why do I want extensibility?  For the situations
I *can't* think of.  If I had thought of them, we could have just stuck it
in the original design.  Therefore any example of why I might need a
pluggable backend can be converted into a new feature the system ought to
have, so I can't ever prove my point by giving an example.

But to give an example from a different area, did you know that once upon a
time, command shells weren't extensible?  There were only so many commands
you could have, and that was it.  Then Unix came along, and nearly *all* the
shell commands were actually subprograms.  It's slower, but it's extremely
powerful.  People do lots of useful things with it that the designers never
imagined.  And really, that's what we want when we design any system.

Oh, also, it's no more work, because it's already implemented in all the
config systems under discussion.  They obviously thought it was a good idea,
and I've already used it to my own advantage.

Have fun,

Avery