From owner-freebsd-arch@FreeBSD.ORG Tue Jul 16 22:06:24 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 849CC68A; Tue, 16 Jul 2013 22:06:24 +0000 (UTC) (envelope-from stevek@juniper.net) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0249.outbound.messaging.microsoft.com [213.199.154.249]) by mx1.freebsd.org (Postfix) with ESMTP id E94305EA; Tue, 16 Jul 2013 22:06:23 +0000 (UTC) Received: from mail40-db9-R.bigfish.com (10.174.16.245) by DB9EHSOBE041.bigfish.com (10.174.14.104) with Microsoft SMTP Server id 14.1.225.22; Tue, 16 Jul 2013 22:06:21 +0000 Received: from mail40-db9 (localhost [127.0.0.1]) by mail40-db9-R.bigfish.com (Postfix) with ESMTP id B7AD3540140; Tue, 16 Jul 2013 22:06:21 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.52; KIP:(null); UIP:(null); IPV:NLI; H:P-EMHUB01-HQ.jnpr.net; RD:none; EFVD:NLI X-SpamScore: -4 X-BigFish: VPS-4(zzbb2dI98dI9371I1432Izz1f42h1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch17326ah8275bh8275dhz2fh2a8h668h839h944hd24hd2bhf0ah1220h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h1898h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h1155h) Received-SPF: pass (mail40-db9: domain of juniper.net designates 66.129.224.52 as permitted sender) client-ip=66.129.224.52; envelope-from=stevek@juniper.net; helo=P-EMHUB01-HQ.jnpr.net ; -HQ.jnpr.net ; Received: from mail40-db9 (localhost.localdomain [127.0.0.1]) by mail40-db9 (MessageSwitch) id 1374012379761135_19021; Tue, 16 Jul 2013 22:06:19 +0000 (UTC) Received: from DB9EHSMHS019.bigfish.com (unknown [10.174.16.249]) by mail40-db9.bigfish.com (Postfix) with ESMTP id B09EF580048; Tue, 16 Jul 2013 22:06:19 +0000 (UTC) Received: from P-EMHUB01-HQ.jnpr.net (66.129.224.52) by DB9EHSMHS019.bigfish.com (10.174.14.29) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 16 Jul 2013 22:06:14 +0000 Received: from stevek-ubuntu (172.25.4.212) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.3.213.0; Tue, 16 Jul 2013 15:06:12 -0700 Date: Tue, 16 Jul 2013 18:06:06 -0400 From: Steve Kiernan To: Jordan Hubbard Subject: Re: General purpose library for name/value pairs. Message-ID: <20130716180606.55ec081c@stevek-ubuntu> In-Reply-To: <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> <717D098F-D07E-45B0-B9F0-8D8BCEF06923@mail.turbofuzz.com> Organization: Juniper Networks Inc. X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.10; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% 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: Tue, 16 Jul 2013 22:06:24 -0000 On Mon, 8 Jul 2013 10:57:17 -0700 Jordan Hubbard wrote: > > 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). What about looking at NetBSD's libprop? PROPLIB(3) FreeBSD Library Functions Manual PROPLIB(3) NAME proplib -- property container object library LIBRARY library ``libprop'' SYNOPSIS #include DESCRIPTION The proplib library provides an abstract interface for creating and manipulating property lists. Property lists have object types for boolean values, opaque data, numbers, and strings. Structure is provided by the array and dictionary collection types. Property lists can be passed across protection boundaries by translating them to an external representation. This external representation is an XML document whose format is described by the following DTD: http://www.apple.com/DTDs/PropertyList-1.0.dtd Property container objects are reference counted. When an object is cre- ated, its reference count is set to 1. Any code that keeps a reference to an object, including the collection types (arrays and dictionaries), must ``retain'' the object (increment its reference count). When that reference is dropped, the object must be ``released'' (reference count decremented). When an object's reference count drops to 0, it is auto- matically freed. The rules for managing reference counts are very simple: o If you create an object and do not explicitly maintain a reference to it, you must release it. o If you get a reference to an object from other code and wish to main- tain a reference to it, you must retain the object. You are respon- sible for releasing the object once you drop that reference. o You must never release an object unless you create it or retain it. Object collections may be iterated by creating a special iterator object. Iterator objects are special; they may not be retained, and they are released using an iterator-specific release function. -- Stephen J. Kiernan Juniper Networks, Inc. stevek_at_juniper.net