Date: Tue, 6 Aug 2013 00:33:51 +0000 From: "Teske, Devin" <Devin.Teske@fisglobal.com> To: Steve Kiernan <stevek@juniper.net> Cc: "arch@freebsd.org" <arch@freebsd.org>, Devin Teske <dteske@freebsd.org>, Jordan Hubbard <jkh@mail.turbofuzz.com> Subject: Re: General purpose library for name/value pairs. Message-ID: <13CA24D6AB415D428143D44749F57D7202005DB6@ltcfiswmsgmb21> In-Reply-To: <13CA24D6AB415D428143D44749F57D7201FC9F3C@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <jkh@mail.turbofuzz.com> wrote:
>>>=20
>>>>=20
>>>> On Jul 8, 2013, at 8:03 AM, Pawel Jakub Dawidek <pjd@freebsd.org> 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 <prop/proplib.h>
>>>=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 - <number>
# String - "string"
# Boolean - <ON|OFF>
# 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?13CA24D6AB415D428143D44749F57D7202005DB6>