Subject: Re: binary plist support
To: Jachym Holecek <>
From: Bill Stouder-Studenmund <>
List: tech-kern
Date: 10/10/2007 09:40:44
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Oct 10, 2007 at 09:24:29AM +0200, Jachym Holecek wrote:
> # Bill Stouder-Studenmund 2007-10-09:
> > On Sat, Oct 06, 2007 at 10:25:03PM +0200, Jachym Holecek wrote:
> > > On the API side, binary encoding is created/parsed by the following
> > > functions:
> > >=20
> > >   bool prop_dictionary_binary_externalize(prop_dictionary_t, uint8_t =
> > >       size_t *);
> > >   bool prop_dictionary_binary_externalize_to_file(prop_dictionary_t,
> > >       const char *);
> > >   prop_dictionary_t prop_dictionary_binary_internalize(uint8_t *, siz=
> >=20
> > Will you be changing prop_dictionary_internalize() to accept either=20
> > format? I think the current prop_dictionary_internalize() should become=
> > prop_dictionary_xml_internalize() and prop_dictionary_internalize() wil=
> > differentiate.
> I've kept the original names for XML, ie. prop_dictionary_internalize()
> parses XML and ${...}_binary_internalize() the bplist format. On some
> thought I think the application is responsible for choosing the right
> format for its data, so I didn't want to put any transparency in the API.

I'm not sure about that. Property dictionaries are based on plists on Mac=
OS X, where plists are plists. It doesn't matter if the plist is binary or=
XML, it's a plist.

My thought is we should have transparent versions of the routines and=20
explicit versions. The transparent versions just call the explicit=20
versions as appropriate. One reason I like this is that the important=20
thing is the property dictionary, not the format of its representation.

Put another way, the users of the prop dictionary routines shouldn't think=
about the format of the representation. Or we should encourage them to not=
think about it and provide convenience routines to encourage them not to.

> The only exception is that ${...}_internalize_from_file() accepts both
> formats (it tries XML first and failing that bplist) because it seemed
> like a nice user convenience -- but I'm easy on this, we can introduce
> ${...}_binary_internalize_from_file() and keep the above convention.

I definitely like this.

Take care,


Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.4.7 (NetBSD)