D-Conf

[Sean Middleditch]

On Fri, 2005-03-04 at 15:43 -0500, Avery Pennarun wrote:
> 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.

A note here, since we seem to be coming at two different angles.  You
are coming from the perspective that we will without doubt use an
existing system, and that the trick is determining which system to use.
I'm coming from the angle that we just started talking about D-Conf,
that actual code (already existing or not) is rather irrelevant, and
that the point of the current discussion is to decide the requisite
features of D-Conf.

It doesn't matter if the feature exists in some configuration system
already.  The question is, do we need the feature.  *IF* an existing
system is used, and it already supports that feature, then great.  But
what if no existing system is used, or if the system that is all around
the best in most ways is missing some particular feature?  If we just
focus on the features that Elektra and GConf have, then you have from
the very very beginning forced us to use Elektra or GConf.  Instead, I
say we pick just the features we need, and decide on the actual
implementation based on whether it supports those features.  Maybe the
implementation will support *more* features.  We might not NEED
backends, but if we do pick an existing solution that already supports
them, that's fine.  But there's a difference between coming in and
saying, "we MUST support backends because Elektra has them," and saying,
"we don't need backends, but if we do happen reuse GConf, we'll get them
free."

I, personally, don't think reusing GConf in its current state is
anywhere near a good idea, and I'm personally disinclined towards
Elektra because it NEEDS pluggable backends due to its lack of real
design - it's just a mass of solutions that you can try to find a
problem to solve with.

If we just say that we're definitely going to take either Elektra or
GConf, and base all our discussions on picking which one, then we're
stuck with Elektra and GConf.  If we instead completely ignore the
existing systems and discuss the actual requirements of a configuration
system, maybe we'll think up something new that none of the existing
systems do - which might not happen if just assume we're using what we
already have and limit our debate to merely which current system is the
better.

I like to call this "design."  ;-)

... that was a rather long "note," sorry.  ^^;

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

That is much better - real reasons to exclude particular dependencies is
actual useful criteria.  :)

Note that "glib" is part of /usr, though, so going back to "must not be
in /usr," you now kill any glib-based implementation for the sole
purpose of handling early-early system bootup, which seems like a
completely unnecessary restriction to make, given that early-early
bootup is outside the problem domain of D-Conf.  Like said above, if the
system is also usable in early-bootup, that's a bonus for sure, but it
shouldn't be a hard requirement for the *Desktop* configuration 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.

Unless the code sucks.  ;-)

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

No, it's quite good form - people with real experience in the relevant
areas are the most useful, generally.  ^_^

If you have a strong reason to believe a feature is very important, you
should definitely say so - just give examples and use-cases with it,
please.  "These gizmo applications need to do blah, and by having the
config system do foo that becomes far more manageable." etc.

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

Nothing wrong with removing requirements.  Removing requirements doesn't
mean deleting existing code, it just means the code isn't required.
Which means that if we DID have to drop it, for whatever possible
reason, we can.

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

This is still not a good reason.  The default backend should support
*every* feature the API exposes.  Let's say you go and write a new
backend that extends the system with some new feature... how is that
going to be usable, exactly, without also extending the API and then
modifying applications to use that new API?  You can just extend the
default backend while you're at it, and not need to be able to switch
them around at runtime.

(Again, if we pick a system that has pluggable backends, I don't think
we should go and delete that code - but we should keep an open mind and
consider that we might not pick such a system, so we should decide
whether pluggable backends is really an important criteria or not for
making the selection of implementation.)

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

While true, I fail to see a connection to this particular discussion.
There's no reason to add a new version of 'cp' when the existing 'cp'
already copies a file with no problems, and when the existing 'cp' can
just be modified if something new does come along - you don't need to
create a front-end to 'cp' to allow users to dynamically swap the
current 'cp' implementation around at will.  That's a bit closer of
analogy to pluggable backends.

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

They thinking it was a good idea doesn't mean much.  The old pre-Unix
system engineers thought it was a good idea to hardcode shell commands,
right?  ;-)

If you have some examples how it's usable, though, please share.  I'm
particularly interested in knowing if you found pluggable backends
useful only because the default backends of the systems in question
simply weren't as good as they should have been.  In that case,
pluggable backends aren't a solution to a problem, they're a hack to
work around fixing the real problem - a suboptimal default
implementation.  That's what I'm REALLY worried about here - will
pluggable backends just be an excuse to punt implementing a good backend
from the start, so we end up with... oh, say... Elektra?

> 
> Have fun,
> 
> Avery
> 
-- 
Sean Middleditch <elanthis at awesomeplay.com>