From owner-freebsd-arch@FreeBSD.ORG Mon Jul 8 22:09:42 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9A30656E; Mon, 8 Jul 2013 22:09:42 +0000 (UTC) (envelope-from jordan.hubbard@gmail.com) Received: from mail-pd0-x234.google.com (mail-pd0-x234.google.com [IPv6:2607:f8b0:400e:c02::234]) by mx1.freebsd.org (Postfix) with ESMTP id 6FC821BF5; Mon, 8 Jul 2013 22:09:42 +0000 (UTC) Received: by mail-pd0-f180.google.com with SMTP id 10so4505756pdi.11 for ; Mon, 08 Jul 2013 15:09:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=nBmSzNzhXQtmeuXpsudmz3KcilAhAjoQ7F2fYzqiFns=; b=iyNcErrJzn3Wj9ckaAwUw8+8iSTGjNwCCjLXYRyBOWEznBAdwQISO4+fjySWDWyCgQ qqSuwhl6u4w9R6UWrRR3jpSQa63PScbPFlQAV7Qq2esJOObd61suKlq5c/lzSeIRhlLs G3JxxpWqaJDLD7HHZcsIjk0K0iHeMtrY5blws8/s0goDunUcAc4tNCt0odqGW+gixFWp FVMLOwJr4lkX+iMRny9EDrnVVcOnKvVwGXWF9lIU88l0xR1+Wtdy9WL+dn36dz0gHmxy BnIrxD/k6fbxz8AbrXT4RH0njrR+MT7uls0LkK3qRjk02Z045nghl8OFV45y+eIZXEia LhzA== X-Received: by 10.66.119.74 with SMTP id ks10mr25081222pab.179.1373321382296; Mon, 08 Jul 2013 15:09:42 -0700 (PDT) Received: from [10.20.30.70] (75-101-82-48.static.sonic.net. [75.101.82.48]) by mx.google.com with ESMTPSA id v20sm26219304paj.4.2013.07.08.15.09.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 08 Jul 2013 15:09:41 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: General purpose library for name/value pairs. From: "Jordan K. Hubbard" In-Reply-To: <20130708213351.GB1405@garage.freebsd.pl> Date: Mon, 8 Jul 2013 15:09:40 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: 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> To: Pawel Jakub Dawidek X-Mailer: Apple Mail (2.1510) Cc: arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 22:09:42 -0000 On Jul 8, 2013, at 2:33 PM, Pawel Jakub Dawidek 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 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