On Oct 6, 2007, at 1:25 PM, Jachym Holecek wrote:

> The binary encoding, which is rather size-efficient and supposedly  
> very
> fast as well (but I don't have numbers yet), is basically Apple bplist
> format. But because Apple doesn't distinguish signed integers vs.  
> unsigned,
> the format differs slightly and uses different version number to avoid
> confusion.

I would like to avoid having a different format.  Is there any  
pressing need to distinguish between signed and unsigned in the  
serialized format?

> On the API side, binary encoding is created/parsed by the following
> functions:
>
>  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 *,  
> size_t);

I would like to see some API changes, here:

- Add new prop_*_externalize_with_encoding() routines that take a  
prop_encoding_t as a final argument:

typedef enum {
	PROP_ENCODING_DEFAULT = 0,
	PROP_ENCODING_XML = 1,
	PROP_ENCODING_BINARY = 2,
} prop_encoding_t;

- prop_*_externalize() should remain, and should be simple wrappers  
around prop_*_externalize_with_encoding(..., PROP_ENCODING_DEFAULT);

- Internally, prop_*_externalize_with_encoding() should map  
PROP_ENCODING_DEFAULT to PROP_ENCODING_XML.

- prop_*_internalize() should simply recognize which encoding is being  
used and handle it.

-- thorpej