Re: unreadable XML proplists from drvctl(8)

[Matthew Mondor <mm_lists%pulsar-zone.net@localhost>]

On Wed, 18 Jan 2012 14:27:10 -0600
David Young <dyoung%pobox.com@localhost> wrote:

> Is JSON a human-readable alternative?
> 
> % drvctl -pn mainbus0 | xmlsed 
> '//{(key/{text()})%((integer|string)/{text()})}' -1 '"$2": $3, ' | xmlsed -E 
> '/{plist/dict/{*}}' -1 '{ $2 }'
> { "device-driver": mainbus, "device-unit": 0x0,  }

Or:

# drvctl -pn mainbus0 | proplist-humanize
{
  
  "device-driver" = "mainbus" 
  "device-unit" = 0 
} 

I think that if drvctl itself could have a switch to export to a
human-readable format it'd be good too (traditional BSD tools do, and
drvctl makes no use of -h currently), yet I'm sure there are other
circumstances where admins are likely to have to read plists in the
future, and want to avoid unnecessary code duplication.

In which case, should proplib itself support an alternative export
format to avoid duplication, such that any application may easily
output an alternative view when it exports a plist, that might be used
by humans?  This would also allow in the future for a variety of
commands to optionally output proplib or JSON in the future, if we
wanted to head in that direction.  Applications could obtain proplibs
and avoid string parsing, and humans could obtain JSON.  Since Lua is
now in the base system, if it can also use plists and obtain them from
the output of a number of commands, this becomes an interesting
alternative to sh for scripting...  and proplib of course doesn't have
to parse JSON for input.

A function such as:

        int prop_object_externalize_json(FILE *);

which could handle both the array or dict case?

Although the above example didn't exactly use JSON, I think that
yes, decently indented JSON would be a good alternative output format
for humans.
-- 
Matt