Re: proplist [was: Importing xmlgrep into base]

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

On Wed, 14 Apr 2010 12:24:10 +0200
Nhat Minh Le <nhat.minh.le%huoc.org@localhost> wrote:

> Now there's also the fact that, as awkward as the XML standard is[1],
> it's still standard, and translating things like processing
> instructions or even attributes to/from s-expressions would require
> more than the commonly accepted subset of "s-exp" as a data
> representation language. We might represent attributes as keyword
> arguments (i.e. `:name value'), and PIs in, say, square brackets
> (i.e. `[target "content"]'). But it'd just be an arbitrary choice; we
> could as well write PIs as `#(target "content")'.

I agree that using a common userland import/export tool would be the
simplest, rather than making proplib(3) itself understand various
formats (other than the binary format which should also be a
proplib-native one).  As for the vipw-like tool, a specialized property
list editor would also be best (a human-usable editor).

It's true that versionning could make things a little more complex with
time also.  After thinking more about it and reading the proplib(3) API
throughly, I think that it's already easy enough to write custom export
tools in C (and import tool is probably best written in the language
for which the export format was created, and that's easy enough to
write as well for people needing it).  So working on a binary format
(for reasons of performance, unrelated to the import/export discussion)
is probably higher priority than supporting alternate text formats.

Just to continue on the s-exp example (I'll then personally drop the
topic until I perhaps eventually post a small import/export utility if
I myself need one, in case others also do).  Indeed there is no
definite language-independent export standard, although there exist
initiatives such as SXML (http://pobox.com/~oleg/ftp/papers/SXs.pdf)
and some RFCs using s-exp derived syntax (i.e. RFC-2693).  However,
considering how simple the proplist data are, it'd be possible to
export to a format which is closest to a language-specific need.

Consider for instance, assuming there was a CL-S-EXP export utility:


/usr/xsrc/external/mit/xorg-server/dist/hw/xquartz/bundle/Xquartz.plist

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" 
"http://www.apple.com/DTDs/PropertyList-1.0.dtd";>

<!-- This file contains system-wide defaults for the Apple X11 server -->

<plist version="1.0">
<dict>
        <key>apps_menu</key>
        <array>
                <array>
                        <string>Terminal</string>
                        <string>xterm</string>
                        <string>n</string>
                </array>
                <array>
                        <string>xman</string>
                        <string>xman</string>
                        <string></string>
                </array>
                <array>
                        <string>xlogo</string>
                        <string>xlogo</string>
                        <string></string>
                </array>
        </array>
</dict>
</plist>

'(:plist (:version "1.0" :encoding "UTF-8")
  (:dict (("apps_menu" #(#("Terminal" "xterm" "n")
                         #("xman" "xman" "")
                         #("xlogo" "xlogo" ""))))))


/usr/src/crypto/dist/heimdal/packages/mac/Info.plist

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" 
"http://www.apple.com/DTDs/PropertyList-1.0.dtd";>
<plist version="1.0">
<dict>
        <key>CFBundleGetInfoString</key>
        <string>Heimdal @VERSION@</string>
        <key>CFBundleName</key>
        <string>Heimdal</string>
        <key>CFBundleIdentifier</key>
        <string>org.h5l.heimdal.pkg</string>
        <key>CFBundleShortVersionString</key>
        <string>1.0</string>
        <key>IFPkgFlagAllowBackRev</key>
        <true/>
        <key>IFPkgFlagAuthorizationAction</key>
        <string>RootAuthorization</string>
        <key>IFPkgFlagDefaultLocation</key>
        <string>/</string>
        <key>IFPkgFlagFollowLinks</key>
        <true/>
        <key>IFPkgFlagIsRequired</key>
        <true/>
        <key>IFPkgFlagOverwritePermissions</key>
        <true/>
        <key>IFPkgFlagRelocatable</key>
        <false/>
        <key>IFPkgFlagRestartAction</key>
        <string>NoRestart</string>
        <key>IFPkgFlagRootVolumeOnly</key>
        <true/>
        <key>IFPkgFlagUpdateInstalledLanguages</key>
        <false/>
        <key>IFPkgFormatVersion</key>
        <real>0.10000000149011612</real>
</dict>
</plist>

'(:plist (:version "1.0" :encoding "UTF-8")
  (:dict (("CFBundleGetInfoString" "Heimdal @VERSION@")
          ("CFBundleName" "Heimdal")
          ("CFBundleIdentifier" "org.h5l.heimdal.pkg")
          ("CFBundleShortVersionString" "1.0")
          ("IFPkgFlagAllowBackRev" t)
          ("IFPkgFlagAuthorizationAction" "RootAuthorization")
          ("IFPkgFlagDefaultLocation" "/")
          ("IFPkgFlagFollowLinks" t)
          ("IFPkgFlagIsRequired" t)
          ("IFPkgFlagOverwritePermissions" t)
          ("IFPkgFlagRelocatable" nil)
          ("IFPkgFlagRestartAction" "NoRestart")
          ("IFPkgFlagRootVolumeOnly" t)
          ("IFPkgFlagUpdateInstalledLanguages" nil)
          ("IFPkgFormatVersion" 0.10000000149011612))))


Such a format is easily readable and parsable by a few lines of CL
code.  In this example, keyword symbols are used to avoid package
issues and aid in identifying sections, plist's "arguments" are a CL
plist, :dict are using a CL alist (yet identified with :dict to easily
distinguish it from other lists), bools are booleans, integers
integers, real floats, and arrays litteral arrays.

Once this representation is read in CL, arrays are directly
aref-indexable and alists assoc-addressable (and easily converted to a
hash table if necessary if lookups should be fast).  A JSON export tool
would also result in a data format easily read and parsed by JS code.

But anyway, I think that I came back to reason and realized that we
don't really need alternate text formats in the base system, unless we
also have another high-level language as part of base.

Thanks,
-- 
Matt