D-Conf

[Sean Middleditch]

On Fri, 2005-03-04 at 13:07 -0500, Avery Pennarun wrote:
> On Fri, Mar 04, 2005 at 10:40:14AM -0500, Sean Middleditch wrote:
> > Does this hypothetical configuration system REALLY need to be designed
> > to handle early boot up or anything like that?  Is that perhaps just a
> > tad bit of over-engineering for a DESKTOP configuration system?  Does
> > early bootup even NEED a new configuration system?  Do the early bootup
> > guys WANT a new configuration system?  The target of the new
> > configuration system is desktop apps, so there's not a whole lot to gain
> > by worrying but applications outside your target application set.
> 
> You're arguing against something that is no work.  The only unusual

The below are definitely things that involve a lot of work.  ;-)

> 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.

> 
>  - 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?

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.

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.
-- 
Sean Middleditch <elanthis at awesomeplay.com>