Date: Mon, 8 Jul 2013 23:33:52 +0200 From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: Jordan Hubbard <jkh@mail.turbofuzz.com> Cc: arch@FreeBSD.org Subject: Re: General purpose library for name/value pairs. Message-ID: <20130708213351.GB1405@garage.freebsd.pl> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --]
Nice to see you back, Jordan:)
On Mon, Jul 08, 2013 at 10:57:17AM -0700, Jordan Hubbard wrote:
>
> 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!).
I do support nested nvlists. Doesn't that fill the gap?
> 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.
FYI, FreeBSD can pass shared memory as file descriptors, see SHM_ANON in
shm_open(2).
> 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).
Interesting.
--
Pawel Jakub Dawidek http://www.wheelsystems.com
FreeBSD committer http://www.FreeBSD.org
Am I Evil? Yes, I Am! http://mobter.com
[-- Attachment #2 --]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (FreeBSD)
iEYEARECAAYFAlHbMD8ACgkQForvXbEpPzRtjwCgx/zgfLEPl6gfbeRWKCsaxUOJ
ILAAnjmBzZEpsfHpeq01R6H9t48HOmNi
=2Q/y
-----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130708213351.GB1405>