From owner-freebsd-arch@FreeBSD.ORG Tue Aug 6 00:33:54 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 B12F0A72; Tue, 6 Aug 2013 00:33:54 +0000 (UTC) (envelope-from Devin.Teske@fisglobal.com) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 797D22FAC; Tue, 6 Aug 2013 00:33:53 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.17]) by ltcfislmsgpa01.fnfis.com (8.14.5/8.14.5) with ESMTP id r760XrPF021848 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 5 Aug 2013 19:33:53 -0500 Received: from LTCFISWMSGMB21.FNFIS.com ([169.254.1.135]) by LTCFISWMSGHT06.FNFIS.com ([10.132.206.17]) with mapi id 14.02.0309.002; Mon, 5 Aug 2013 19:33:52 -0500 From: "Teske, Devin" To: Steve Kiernan Subject: Re: General purpose library for name/value pairs. Thread-Topic: General purpose library for name/value pairs. Thread-Index: AQHOeQDhn1IH8mH3sEeIpLvmIzmJnZlV/ouAgADVwICAAAT1AIAEYRIAgAAwqICADNgsAIAACViAgAACpwCAH4voAA== Date: Tue, 6 Aug 2013 00:33:51 +0000 Message-ID: <13CA24D6AB415D428143D44749F57D7202005DB6@ltcfiswmsgmb21> 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> <13CA24D6AB415D428143D44749F57D7201FC9EED@ltcfiswmsgmb21> <13CA24D6AB415D428143D44749F57D7201FC9F3C@ltcfiswmsgmb21> In-Reply-To: <13CA24D6AB415D428143D44749F57D7201FC9F3C@ltcfiswmsgmb21> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.126] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-08-05_07:2013-08-05,2013-08-05,1970-01-01 signatures=0 Cc: "arch@freebsd.org" , Devin Teske , Jordan Hubbard X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Devin Teske List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 00:33:54 -0000 On Jul 16, 2013, at 3:49 PM, Teske, Devin wrote: >=20 > On Jul 16, 2013, at 3:39 PM, Teske, Devin wrote: >=20 >>=20 >> On Jul 16, 2013, at 3:06 PM, Steve Kiernan wrote: >>=20 >>> 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 wrot= e: >>>>=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 li= st API (but without serialization and quite a few other things), keeping th= e number of supported types down is much better than the converse - exposin= g the details of 16/32/64 bit numbers and their signedness will hang you ov= er the long term, and you can always provide explicit conversion functions = to/from Number for those who actually care. >>>>=20 >>>> String, Number, Boolean, Data, Date, Array and Dictionary are all plis= ts support, and Apple developers have gotten along pretty well for many yea= rs 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 a= lso added out-of-band types like file and shared memory descriptors. You h= ave file descriptors, but not shared memory. The latter is kind of importa= nt if you want to do larger IPCs with this mechanism someday and want to su= pport "big payloads" transparently without passing the burden of the data m= anagement to the application programmer. >>>>=20 >>>> Before you also come back with "but but this is a kernel API! For jus= t 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 ty= pes 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 = the dictionary type) , bingo, now you have a preferences API that FreeBSD h= as lacked from day one ("just roll your own format and stick the file in /e= tc" being the canonical response to that need). >>>=20 >>> What about looking at NetBSD's libprop? >>>=20 >>> PROPLIB(3) FreeBSD Library Functions Manual PRO= PLIB(3) >>>=20 >>> NAME >>> proplib -- property container object library >>>=20 >>> LIBRARY >>> library ``libprop'' >>>=20 >>> SYNOPSIS >>> #include >>>=20 >>> 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 pr= ovided >>> by the array and dictionary collection types. >>>=20 >>> Property lists can be passed across protection boundaries by transl= ating >>> them to an external representation. This external representation i= s an >>> XML document whose format is described by the following DTD: >>>=20 >>> http://www.apple.com/DTDs/PropertyList-1.0.dtd >>>=20 >>> Property container objects are reference counted. When an object i= s cre- >>> ated, its reference count is set to 1. Any code that keeps a refer= ence >>> to an object, including the collection types (arrays and dictionari= es), >>> must ``retain'' the object (increment its reference count). When t= hat >>> reference is dropped, the object must be ``released'' (reference co= unt >>> decremented). When an object's reference count drops to 0, it is a= uto- >>> matically freed. >>>=20 >>> The rules for managing reference counts are very simple: >>>=20 >>> o If you create an object and do not explicitly maintain a refere= nce to >>> it, you must release it. >>>=20 >>> 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 re= spon- >>> sible for releasing the object once you drop that reference. >>>=20 >>> o You must never release an object unless you create it or retain= it. >>>=20 >>> Object collections may be iterated by creating a special iterator o= bject. >>> Iterator objects are special; they may not be retained, and they are >>> released using an iterator-specific release function. >>>=20 >>=20 >> There's also my own "figpar" free for the taking... >>=20 I don't know if I was off the mark with my suggesting figpar for the job...= but... I realized that some examples are necessary to actually bring it ho= me as a contender. I recently needed to be able to read the key/value pairs stored in ~/.dialo= grc (generated by "dialog --create-rc ~/.dialogrc"). The format of which is= simple enough... (from the head of a freshly-generated ~/.dialogrc): # Types of values: # # Number - # String - "string" # Boolean - # Attribute - (foreground,background,highlight?) Simple enough... figpar did the job wonderfully. Check it out... http://druidbsd.cvs.sf.net/viewvc/druidbsd/fdpv/dialogrc.h?revision=3D1.4&v= iew=3Dmarkup&pathrev=3Dfdpv_0_4 http://druidbsd.cvs.sf.net/viewvc/druidbsd/fdpv/dialogrc.c?revision=3D1.12&= view=3Dmarkup&pathrev=3Dfdpv_0_4 NOTE: If you looked at figpar before, have another look. I made it style(9)= compatible and enhanced it slightly. http://druidbsd.cvs.sf.net/viewvc/druidbsd/fdpv/figpar.h?revision=3D1.11&vi= ew=3Dmarkup&pathrev=3Dfdpv_0_4 http://druidbsd.cvs.sf.net/viewvc/druidbsd/fdpv/figpar.c?revision=3D1.7&vie= w=3Dmarkup&pathrev=3Dfdpv_0_4 --=20 Cheers, Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you.