# Bill Stouder-Studenmund 2007-10-10:
> On Wed, Oct 10, 2007 at 09:24:29AM +0200, Jachym Holecek wrote:
> > 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 
> explicit versions. The transparent versions just call the explicit 
> versions as appropriate. One reason I like this is that the important 
> 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 APIs mentioned above operate on memory buffers -- in that situation
you need to have some knowledge about it's encoding: if it's binary you
need to remember exact length; if it's XML the code will assume it's a
nul-terminated cstring. So transparency at this level sounds problematic.

Do you have a pointer to Apple API specification? Maybe there's something
to be learned.

> > 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.

When dealing with files, I think the "I want a plist so give me a plist"
principle you mentioned applies just fine -- archieving transparency is
easy and natural since we've got all the needed info at our hands already.

	-- Jachym