From owner-freebsd-arch@FreeBSD.ORG Thu Jul 25 22:28:47 2013 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id F178864F for ; Thu, 25 Jul 2013 22:28:46 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (garage.dawidek.net [91.121.88.72]) by mx1.freebsd.org (Postfix) with ESMTP id 85D9F240A for ; Thu, 25 Jul 2013 22:28:46 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 11134241; Fri, 26 Jul 2013 00:09:36 +0200 (CEST) Date: Fri, 26 Jul 2013 00:15:17 +0200 From: Pawel Jakub Dawidek To: Steve Kiernan Subject: Re: General purpose library for name/value pairs. Message-ID: <20130725221517.GH1400@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> <20130716180606.55ec081c@stevek-ubuntu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZYOWEO2dMm2Af3e3" Content-Disposition: inline In-Reply-To: <20130716180606.55ec081c@stevek-ubuntu> X-OS: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: arch@freebsd.org, Jordan Hubbard 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: Thu, 25 Jul 2013 22:28:47 -0000 --ZYOWEO2dMm2Af3e3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 16, 2013 at 06:06:06PM -0400, Steve Kiernan wrote: > On Mon, 8 Jul 2013 10:57:17 -0700 > Jordan Hubbard wrote: >=20 > >=20 > > On Jul 8, 2013, at 8:03 AM, Pawel Jakub Dawidek wrote: > >=20 > > > How about instead of supporting int8, uint8, int16, uint16, int32, > > > uint32, int64 and uint64 I'd just support 'number' type, which would = be > > > uint64_t. This shouldn't break transporting signed values and because= I > > > don't support basic types like int, long, etc. casting or conversion = has > > > to be done anyway. This would reduce number of supported types to: > >=20 > > That's a good idea. Since you're re-inventing Apple's XML property lis= t API (but without serialization and quite a few other things), keeping the= number of supported types down is much better than the converse - exposing= the details of 16/32/64 bit numbers and their signedness will hang you ove= r the long term, and you can always provide explicit conversion functions t= o/from Number for those who actually care. > >=20 > > String, Number, Boolean, Data, Date, Array and Dictionary are all plist= s support, and Apple developers have gotten along pretty well for many year= s 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 > > When Apple extended the Plist metaphor for IPC (to create XPC), they al= so added out-of-band types like file and shared memory descriptors. You ha= ve file descriptors, but not shared memory. The latter is kind of importan= t if you want to do larger IPCs with this mechanism someday and want to sup= port "big payloads" transparently without passing the burden of the data ma= nagement to the application programmer. > >=20 > > Before you also come back with "but but this is a kernel API! For just= one purpose!" let me just say that it's absolutely achievable to have ONE = API for talking userland<->kernel and userland<->userland with the same typ= es and the transport mechanism(s) largely abstracted away. You don't need = two - it's already been done with one, just look next door. :) > >=20 > > If you add file serialization of this format to your picture (and add t= he dictionary type) , bingo, now you have a preferences API that FreeBSD ha= s lacked from day one ("just roll your own format and stick the file in /et= c" being the canonical response to that need). >=20 > What about looking at NetBSD's libprop? Someone already suggested that, but libprop is much much more complex than libnv. I really want something extremely easy to use, so it can be adopted quickly. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com --ZYOWEO2dMm2Af3e3 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iEYEARECAAYFAlHxo3UACgkQForvXbEpPzT6cQCfVNm1+zYwgeZRETQqvZgBHgrC +gAAmwdX6e7K/l3AfSaYUXtFUqT27+KR =6OOn -----END PGP SIGNATURE----- --ZYOWEO2dMm2Af3e3--