General purpose library for name/value pairs.

[Jordan K. Hubbard]

On Jul 8, 2013, at 2:33 PM, Pawel Jakub Dawidek <pjd at FreeBSD.org> wrote:

> Nice to see you back, Jordan:)

Thanks!   Now that I'm CTO of iXSystems (and no longer behind Apple's communications firewall), you can expect to see me around more often!   Not sure if that's a bug or a feature as far as this list is concerned, but I'll do my best to make it a positive. :)

>> String, Number, Boolean, Data, Date, Array and Dictionary are all plists support, and Apple developers have gotten along pretty well for many years with that set (not supporting Dictionaries, btw, is a pretty fundamental loss IMHO - it means you have to always iterate through lists to find your stuff, which is meh!).
> 
> I do support nested nvlists. Doesn't that fill the gap?

Not really, no.  In fact, once you support dictionaries, you'll find that most people prefer them to lists since data can now be passed in order-independent fashion and evolved over time without breaking older code.  Arrays/lists are far less general purpose and used much less often (when I checked through a bunch of preference plists on one of my OS X boxes, I found arrays of <data> types to be the most common).  Nested dictionaries are even far more common in general practice.

> FYI, FreeBSD can pass shared memory as file descriptors, see SHM_ANON in
> shm_open(2).

OS X supports this as well.  The reason we make it an explicit type is for two reasons.  One is lifecycle management - you can't just close a fd representing a shared memory segment and have all the right things happen on last close (the segment itself won't be GC'd).  The second reason is that both ends want a fd in one case and an address in the other and it would be weird to mix and match metaphors just because the transport wanted to canonicalize everything into fds.

- Jordan