Subject: Re: proplib changes
To: None <tech-kern@netbsd.org>
From: Trevor Talbot <quension@gmail.com>
List: tech-kern
Date: 06/26/2007 16:02:39
[ old reply, I screwed up and missed the list ]

On 6/26/07, Thor Lancelot Simon <tls@rek.tjls.com> wrote:
> On Tue, Jun 26, 2007 at 01:06:10AM -0700, Trevor Talbot wrote:
> > On 6/26/07, Thor Lancelot Simon <tls@rek.tjls.com> wrote:

> > >What you're missing is that "the tools" in this case means "any
> > >proplib-using application".  It doesn't matter if you write a boot
> > >properties list in XML or SCN, it looks the same to proplib internally;
> > >and, similarly, it can output that list of boot properties in XML or
> > >SCN, as you like.

> > But the issue is what happens when there's an existing configuration
> > file I want to edit.  If it's in one of the 7,999 formats I'm not
> > comfortable with, I have to use another tool just to get it into a
> > form where I can edit it.  (And there's still the issue of

> No: proplib can not only internalize, but also externalize every format
> it can read; so you never need "another tool", only the program that
> stores and uses data in proplib in the first place.  It can write any
> valid configuration back out in any format.

Only if it's willing (key phrase "valid configuration").  See my
previous response in this thread.

> The comment issue, unfortunately, is a generic proplib issue, unless you
> are never going to let programs externalize the data you load into them,
> which would lose a lot of the point of using proplib at all.

The way I see it, there are two orthogonal issues here:

1 - Applications that provide an interface to manipulate their own
configuration data and need a storage system for it.  That storage
system being human-editable is no small bonus, but not the primary
goal.  The boot properties work is a great example.

2 - Applications that want an excellent configuration format for human
use.  They read it, and may do some manipulation, but the primary goal
is to be a human-friendly format.

Proplib is designed for (1) and does it quite well.  It's not equipped
to handle (2).  Trying to make it handle (2) just adds complexity
without actually reaching the goal, and the complexity itself makes
the system frustrating and fragile.

Thus, "8,000 Different Syntaxes Considered Harmful".