Jason Thorpe wrote:
>
> On Jun 6, 2006, at 3:17 PM, Garrett D'Amore wrote:
>
>> I'd really like to have a binary plist format -- passing around large
>> ascii representations of data seems "ugly" to me. Especially across a
>> kernel/user boundary.
>
> I'm working on one (compatible with Apple's) in all that spare time I
> have. (Sorry, finishing the remodel of my new house has higher priority.)

Heh. I understand. And thank-you.
>
>> This would also discourage folks from trying to "inspect" or "inspect &
>> modify" encoded plists. The encoded (packed) plist format should be
>> closed.
>
> XML plists are explicitly designed to be human readable / editable.
> They're not "packed" so much as "serialized".

Understood. I believe that there is a real need for a binary format that
has a higher priority on efficiency. But it looks from above like you're
already working on that.

Is it easy to tell that a buffer contains a binary vs. an XML-ified
plist programmatically?

>
>> At some level, I think it is also true that versioning would not be
>> needed if the API boundary for applications was at the library level.
>> But since we provide compatibility for all static binaries, *every*
>> interface like this has to be versioned. Gak.
>
> How do you mean? One of the beauties of dictionaries is that if you
> need to add keys, old code continues to work because they simply
> ignore all the new information. You lose if you REMOVE keys, but...

It wasn't so much the content of what was in the dictionaries that was a
concern, but the format of the dictionary itself to which I was referring.

>
> -- thorpej


-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191