Subject: Re: Changes for proplib to reduce kernel bloat
To: Chapman Flack <firstname.lastname@example.org>
From: Jason Thorpe <email@example.com>
Date: 05/11/2006 15:01:24
On May 11, 2006, at 7:02 AM, Chapman Flack wrote:
> In defense of Jason's bikeshed -
> - it's using, IIUC, a strict subset of XML just adequate to export its
> own stuff, so the only reason for it to set off anybody's XML-alarm
> would be the spelling of its tokens, not the inherent complexity of
> its parser.
That is correct. It is not a general XML parser. It parses only
> - that presumably means that you couldn't expect proplib to parse
> arbitrary output from XML tools, but you could expect existing
> general purpose XML tools to do useful things with proplib output
> if you wanted to.
> - the choice was based, IIUC, on prior art from Apple. Even if that
> has no direct technical benefit (this kind of device-dependent stuff
> might never be exchanged between OSs), it still offers a kind of
> conceptual harmony to people who might administer both NetBSD and OSX
Not just conceptual harmony for those who admin both (OS X admins
don't fiddle with plists manually very often, if at all). Basically,
I saw Apple XML plists as prior art for a file format that was
extremely flexible and human editable. If I wanted to do it in some
other markup language, I would have had to define another DTD-
analogue, and honestly I didn't see the point in divergence for
divergence's sake. Besides, would a general YAML parser be smaller
than my specialized plist parser?
Sure, Apple has other file formats for plists (like a very compact
and fast-to-parse binary plist format), but they're not human
readable / editable with standard text tools. I could certainly
entertain the idea of being able to externalize to / internalize from
that format... but it is also desirable to keep the text form at the
same time, for other reasons.