D-Conf

[Avery Pennarun]

On Sat, Mar 05, 2005 at 12:31:41AM -0500, Sean Middleditch wrote:

> 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.
[...]
> I like to call this "design."  ;-)

Actually it's not, it's "requirements gathering".  In software engineering
that's one of the steps that comes well before design.

I suppose you're right about this, and I'm glad you called me on it.  I
guess I jumped ahead of myself when I realized that every single requirement
listed so far has already been met by Elektra or gconf-on-dbus.  Go through
them; it's true.

I'd add an extra requirement that should be implicit in every program
specification: do the least amount of work possible to create an elegant
solution.  In that case, if an elegant solution exists that already meets
the requirements (gconf-on-dbus and elektra both apply here), you should not
be doing any work.

So okay, I will stop arguing in favour of feature just because they already
exist.  In exchange, I put out this challenge: identify a feature that we
*require* that is *not* already met by gconf-on-dbus and elektra.  Those are
really the ones worthy of discussion.

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

Not exactly.  If I'm making an operating system, which I coincidentally am,
I have the option of moving a few small things to /bin when I start needing
them during bootup.  glib and dbus are libraries that may be sensible to do
this to.  CORBA is (God help us all) not.  Elektra would be better.

But just because it *is* in /usr doesn't mean it *must* be in /usr, so this
remains an option.

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

Sure.  But it doesn't.  I've read the code for gconf and elektra.  The
command-line interface for gconf kinda sucks, but the code itself is fine. 
And post-CORBA gconf should be fine (although I admit to not having read the
code for that one).

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

Since half of my argument has been "but it already does", and the other half
has been "and we really would like it for these reasons", then I think the
most we should do with these requirements is downgrade them to "would be
nice".  In other words, tell the designer to consider throwing these things
in if it's easy, and leaving them out if it's not.

Completely eliminating less-important requirements from the list
unnecessarily blinds the architect and produces worse software.  Sorting
them in order of priority is better.

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

Ha ha!  That's like saying the Unix shell should have a built-in command for
everything you might want to do.  Is that not *obviously* wrong?  Can I even
*list* all the things I might want to do with the shell someday?

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

Semantic completeness.  You can do a *huge amount* of stuff with
open/read/write/iterate/notify, which is the basic API of any relatively
powerful config system.

For example, by implementing just those primitives, you can make a
non-network-aware system, like GConf or elektra, network-aware - I know, I
did it.  You can then make it low-latency network-aware so you don't lose
performance - I did that too.  You can replicate settings in real-time
between a peer-to-peer cluster of servers where any of them can die at any
moment - I did that.  And you can join Gnome and KDE into the same storage
repository that has all these features, without writing the code twice -
that was one of the first things I did, the core of UniConf.

Are you going to tell me that "replicate settings in real-time between a
peer-to-peer cluster of servers where any of them can die at any moment" is
going to be one of the core requirements of D-Conf?  Well, I need that
feature, so if it's not, I can't use your system.  And those are just the
things I thought of *so far*.  Why restrict me when you don't have to?

With pluggable backends, I can do all these things, without forking the core
of your system, even if I can't convince the maintainer that those features
are widely useful (and so far, I can't, and haven't even tried, because it
would be a seriously tough sell).

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

Years ago using Solaris, I happily replaced its versions of "cp" and "ls"
and "grep" with the massively better GNU ones.  Did you know that Solaris
grep only handles lines of 1024 characters or less, or it will silently not
match your pattern?  Well, I have two choices: convince upstream (Sun) that
my problem is important, or replace my own copy of grep.

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

They thought it was a good idea *and I've already used it to my own
advantage*, I said.

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

You must have noticed by now that *all* software's implementation is *badly*
suboptimal.  If your argument hinges around the theory that "We'll just make
it perfect, then why should we need extensibility," and we can't convince
you otherwise, I'm afraid the whole world is doomed :)

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

Actually, Elektra's backend is really not too bad.  The only reason I don't
bother defending it is that it's optional.  That doesn't mean it was bad
because it was pluggable (in fact, Avi had to be talked into making his
backends pluggable *after* the fact).  It just means it *hasn't been
defended* because it's pluggable.

The goofy XML storage backend in GConf is much worse.  (And before anyone
complains, I'm not totally against XML.  I'm against *goofy* XML, which the
GConf schema unarguably is.  Just go look at it!)

UniConf's default "ini file" backend has some flaws, too, like any flat text
file will.  KConfig's is very slightly worse than that.  LDAP is awful, but
it's better than nothing.  How will you ever find a single storage backend
that solves all the world's problems?

Have fun,

Avery