Jason Thorpe wrote:
>
> On May 11, 2006, at 7:02 AM, Chapman Flack wrote:
>
>
> 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?

Having looked at YAML I doubt it.
>
> 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.

A binary format was what I had in mind when I made my suggestion that we
*might* want to consider an alternative to the current
format-that-looks-like-XML-but-is-really-just-a-strict-subset. :-)  If
apple has a nice one ready to use, then I can see no reason to invent
another one.

Is there some reason that the exchange across kernel boundaries should
be done in a human editable format?  The only thing I can think of is to
allow the kernel to directly read configuration data from a filesystem
that was previously hand-edited.

But, I perceive that the drawback to such might be larger kernels,
larger data sizes (assuming a binary representation would be more
compact) and longer run times encoding/decoding the data, in what
*might* be some time sensitive loops.  (As an example, I imagine using
"packed" plists as a way to exchange generalized event notifications
across a kernel/user boundary.  If you have a number of these happening
a second, you'll want it to be *fast*.  In fact, Solaris does precisely
this with their sysevent architecture using packed "nvlists", which are
similar in some ways to plists.)

If I had a vote, I'd vote for a compact binary representation in the
kernel (and across the kernel boundary), and tools in userland to help
manipulate/convert them.  (I'm not sure I have a vote, but I can express
my opinion, can't I? :-)

    -- Garrett

-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191