Date: Mon, 8 Jul 2013 15:09:40 -0700 From: "Jordan K. Hubbard" <jordan.hubbard@gmail.com> To: Pawel Jakub Dawidek <pjd@FreeBSD.org> Cc: arch@FreeBSD.org Subject: Re: General purpose library for name/value pairs. Message-ID: <D2E98A8F-F765-4A56-96CD-4410944A2910@turbofuzz.com> In-Reply-To: <20130708213351.GB1405@garage.freebsd.pl> References: <20130704215329.GG1402@garage.freebsd.pl> <4818.1373008073@critter.freebsd.dk> <20130705195255.GB25842@garage.freebsd.pl> <60317.1373055040@critter.freebsd.dk> <20130708150308.GE1383@garage.freebsd.pl> <717D098F-D07E-45B0-B9F0-8D8BCEF06923@mail.turbofuzz.com> <20130708213351.GB1405@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jul 8, 2013, at 2:33 PM, Pawel Jakub Dawidek <pjd@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!). >=20 > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D2E98A8F-F765-4A56-96CD-4410944A2910>