Subject: Re: Kernel config file
To: Johnny Billquist <bqt@softjar.se>
From: Bill Stouder-Studenmund <wrstuden@netbsd.org>
List: tech-kern
Date: 06/18/2007 21:19:36
--0OAP2g/MAC+5xKAE
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Jun 18, 2007 at 03:39:25PM +0200, Johnny Billquist wrote:
> Jared D. McNeill skrev:
> >Users shouldn't have to edit config files. proplib enables us to build=
=20
> >tools to move away from having to do this kind of crap. The fact that=20
> >our plist format happens to be in a format that is easily modified with=
=20
> >a text editor should be viewed as a feature, not a bug.
>=20
> You know, Microsoft Windows already have this approach, and I don't know=
=20
> how many times I personally, and people nearby, have cursed that.
> Being able to edit the file yourself, and actually know *everything* it=
=20
> says, instead of relying on tools that are doing things you have no=20
> control over is considered an advantage for some people.

How exactly did we get from XML to the Windows Registry?

When you put it the way you did above, you very much sound like a Luddite.=
=20
There are many things that Windows does, like boot off of a disk or have=20
windows and command lines, that we do as well. Given the approach you take=
=20
in this note, should we really stop doing that as well?

I don't think so, and I doubt that's what you meant. As such, please think
about specifics of what you like and don't like. I think we will be
better-able to address issues that way.

I dislike the Windows Registry. My personal displeasure with the Registry
is two-fold. 1) There was no access control for parts (AFAICT). As such,
one program could screw it up for the whole box. I doubt we'll ever do
this.

2) it used hideously long identifiers for things and uses them as keys to
index entries. I'm not sure if they were uuids or something as large. But
it was vile to look at the "drivers"  area and see twenty-character hex
strings. It's one thing to use long strings (say UUIDs), it's another to=20
have to understand/recognize them to understand a config file. I hope we=20
don't end up needing to do this. I also doubt we will.

As to your comments about not having to use tools, well we always use=20
tools now. We just use ones named "vi" or "emacs" (or "ed" for the truly=20
insane). Needing to use different ones doesn't seem like that big a deal.

Well, I do grant you the fact that we need a good plist editor. I think we=
=20
really really need one and we don't have one.

As to "what's so cool about XML," people have said it but you didn't hear=
=20
them. There are a few reasons, but the big one for me is that we end up=20
with multi-stage parsers. The first stage understands the XML, and the=20
second stage or layer understands what the XML is describing.

One advantage is that we can future-proof tools. If a tool looks for a=20
certain object hierarchy in a file, as long as it's there, it works. So we=
=20
can add extra elements over time that older tools can safely ignore. Also,=
=20
I believe we can make it so that said tool can update the config and not=20
botch the other sections, assuming that the unchanged sections did not=20
need to be consistent with the changed sections; we read in a DOM, twiddle=
=20
part of it, then save the whole thing.

Sure, we can do this with other tools and parsers, but it's a lot harder.=
=20
More importantly, we end up reinventing the wheel a lot more each time.

Another way to look at the future-proofing and the multi-stage parsing is=
=20
that we can have stuff in a config file that the tool doesn't understand=20
yet it can safely ignore. As long as the extra stuff is correct proplib=20
stuff (XML or SCN), the tool knows how to parse the extra stuff enough to=
=20
figure out whats there and where it starts & ends. I spoke of stuff for=20
future proofing (different versions of the same tool), but it can also be=
=20
that we have different tools reading the same file.

There are other advantages too, but I'm not sure how much they matter for=
=20
how we write programs. One is that with internalize & externalize, loading=
=20
a config file becomes synonymous with initializing a data structure=20
(coincidentally with the contents of the file). Saving the config is the=20
same thing as exporting the data structure. XML RPC becomes synonymous=20
with transporting a data structure over a network connection. And back.

Sure, it's not something we can't do other ways. It's more a matter of how=
=20
much easier it makes for us to write code and build tools.

Take care,

Bill

--0OAP2g/MAC+5xKAE
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (NetBSD)

iD8DBQFGd1lYWz+3JHUci9cRAvXOAJ9OtSvdhfmo0q72sH08rXmhkiIpOQCfZEyW
zY9KTOsLyY2EW7pr595GSnA=
=0j+D
-----END PGP SIGNATURE-----

--0OAP2g/MAC+5xKAE--