From owner-freebsd-arch@FreeBSD.ORG Mon Jul 8 17:57:56 2013 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 184576DE; Mon, 8 Jul 2013 17:57:56 +0000 (UTC) (envelope-from jkh@mail.turbofuzz.com) Received: from mail.crittercasa.com (mail.turbofuzz.com [208.87.221.144]) by mx1.freebsd.org (Postfix) with ESMTP id 04C401F15; Mon, 8 Jul 2013 17:57:55 +0000 (UTC) Received: from [10.20.30.11] (75-101-82-48.static.sonic.net [75.101.82.48]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.crittercasa.com (Postfix) with ESMTPS id 28C3416487D; Mon, 8 Jul 2013 10:37:45 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1783\)) Subject: Re: General purpose library for name/value pairs. From: Jordan Hubbard In-Reply-To: <20130708150308.GE1383@garage.freebsd.pl> Date: Mon, 8 Jul 2013 10:57:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <717D098F-D07E-45B0-B9F0-8D8BCEF06923@mail.turbofuzz.com> 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> To: Pawel Jakub Dawidek X-Mailer: Apple Mail (2.1783) 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 17:57:56 -0000 On Jul 8, 2013, at 8:03 AM, Pawel Jakub Dawidek wrote: > 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: That's a good idea. Since you're re-inventing Apple's XML property list = 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 over the long term, and you can always provide explicit = conversion functions to/from Number for those who actually care. 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!). When Apple extended the Plist metaphor for IPC (to create XPC), they = also added out-of-band types like file and shared memory descriptors. = You have file descriptors, but not shared memory. The latter is kind of = important if you want to do larger IPCs with this mechanism someday and = want to support "big payloads" transparently without passing the burden = of the data management to the application programmer. 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 types and the transport mechanism(s) largely abstracted away. You = don't need two - it's already been done with one, just look next door. = :) If you add file serialization of this format to your picture (and add = the dictionary type) , bingo, now you have a preferences API that = FreeBSD has lacked from day one ("just roll your own format and stick = the file in /etc" being the canonical response to that need). - Jordan