Date: Mon, 8 Jul 2013 10:57:17 -0700 From: Jordan Hubbard <jkh@mail.turbofuzz.com> To: Pawel Jakub Dawidek <pjd@freebsd.org> Cc: arch@FreeBSD.org Subject: Re: General purpose library for name/value pairs. Message-ID: <717D098F-D07E-45B0-B9F0-8D8BCEF06923@mail.turbofuzz.com> In-Reply-To: <20130708150308.GE1383@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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jul 8, 2013, at 8:03 AM, Pawel Jakub Dawidek <pjd@freebsd.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?717D098F-D07E-45B0-B9F0-8D8BCEF06923>