Subject: Re: proplib changes
To: NetBSD Kernel Technical Discussion List <tech-kern@NetBSD.org>
From: Greg A. Woods <woods@planix.com>
List: tech-kern
Date: 06/28/2007 18:39:38
--pgp-sign-Multipart_Thu_Jun_28_18:39:34_2007-1
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

At Thu, 28 Jun 2007 16:39:24 -0400, Allen Briggs wrote:
Subject: Re: proplib changes
>=20
> On Thu, Jun 28, 2007 at 03:58:42PM -0400, Greg A. Woods wrote:
> > 1. the relatively arbitrary choice of using the enormous bloat of XML
> >    syntax was made unilaterally (just because other mostly proprietary
> >    systems chose it doesn't mean it's the right choice)
>=20
> I don't think it was relatively arbitrary.  It's been used in several
> places and does seem to serve the purpose well enough in those places.

Well it was certainly as arbitrary as any other choice would have been
in the context that it was not really discussed beforehand.

> > 2. since despite the fact that XML syntax is in a textual format it's
> >    still not really human friendly (incredibly unfriendly, actually),
>=20
> The parenthetical, at least, seems to be at least somewhat subjective.

No doubt it is subjective.  I can't argue against that!  :-)

You can feed The People Solient Green if you have the right propaganda
to market it to them.

Just because some portion of the world has become enamored with the
various SGML derivatives doesn't mean the whole world needs to have such
syntax forced upon us.  Clearly I'm far from the only person who finds
such syntax baroque and difficult to read.

Lines of code comparisons of parsers prove clearly that it's more
difficult to parse too.


> I don't think the unfriendliness-to-some/many was really recognized
> until after the fact.  In which case, it's hard to see how the need
> for a tool could have been anticipated.

That's the problem with making relatively arbitrary choices without
really considering the issues in the widest possible scope.

Heck back when proplib was first discussed I did some very simple
off-the-cuff searches on google and freshmeat for simple generic
configuration file formats and for what people thought about XML as the
basis for generic configuration file formats.  Admittedly my search
terms were no doubt biased in some ways, but I very quickly found lots
of justification for why XML is a bad choice.  Had the introduction of
proplib been _preceded_ by such searches then perhaps the choice of XML
would have been more carefully considered _before_ the fact.

One of the best references that I can still find in 5 minutes is:

    http://www-128.ibm.com/developerworks/xml/library/x-sbxml.html

The introduction to LUA also has some sage advice about extension and
configuration language syntax:

	http://www.lua.org/spe.html

There's tons of prior art and some of it is far more widely used than
proplists.  No really good rationale has been given for apparently
ignoring it all.  One could even go so far as to turn the
N.I.H. argument back at Jason for having apparently ignored all the
other existing prior art.


> I have yet to meet a proplist that's a pain to deal with.  Raw XML,
> I've had problems with, but proplists, no.

Not accepting the fact that proplists _are_ raw XML is already well down
the path to BIG trouble -- witness the issues with comment handling.

We haven't even begun to discuss the potential issues of syntax error
handling.

The more syntax there is, and SGML derivatives have more than enough
syntax, the more possibilities there are for errors and the more need
there is for intelligent error handling.

This is one place where, for example, the BIND-{8,9} configuration file
syntax and its parser are also both quite good, and very bad, depending
on which angle you approach it from.

--=20
						Greg A. Woods

H:+1 416 218-0098 W:+1 416 489-5852 x122 VE3TCP RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>       Secrets of the Weird <woods@weird.com>

--pgp-sign-Multipart_Thu_Jun_28_18:39:34_2007-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 5.0i for non-commercial use
MessageID: XqL5OKsIA8lYU+Hvs8ZPj9LTVu3oyRxG

iQA/AwUBRoQ4pmZ9cbd4v/R/EQKigQCdFFH1rs9cyO35cYQ5vLOHLMXG9+0AmgP0
M/I2zmReVb2fTx79cwUxPQKK
=eWSA
-----END PGP SIGNATURE-----

--pgp-sign-Multipart_Thu_Jun_28_18:39:34_2007-1--