--5mCyUwZo2JvN/JJP
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=
e_t);
> >=20
> > Will you be changing prop_dictionary_internalize() to accept either=20
> > format? I think the current prop_dictionary_internalize() should become=
=20
> > prop_dictionary_xml_internalize() and prop_dictionary_internalize() wil=
l=20
> > differentiate.
>=20
> 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=
=20
OS X, where plists are plists. It doesn't matter if the plist is binary or=
=20
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=
=20
about the format of the representation. Or we should encourage them to not=
=20
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,

Bill

--5mCyUwZo2JvN/JJP
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (NetBSD)

iD8DBQFHDQCMWz+3JHUci9cRAh/RAJ9VXFsTLCZjyAx55FnJM25QUQ1MSwCgk7AE
ykLlwVnd43nhlKTHDwoWQoE=
=WUYs
-----END PGP SIGNATURE-----

--5mCyUwZo2JvN/JJP--