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
--K8nIJk4ghYZn606h
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Nice to see you back, Jordan:)
On Mon, Jul 08, 2013 at 10:57:17AM -0700, Jordan Hubbard wrote:
>=20
> On Jul 8, 2013, at 8:03 AM, Pawel Jakub Dawidek <pjd@freebsd.org> wrote:
>=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 list =
API (but without serialization and quite a few other things), keeping the n=
umber of supported types down is much better than the converse - exposing t=
he 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/=
=66rom Number for those who actually care.
>=20
> 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 lo=
ss IMHO - it means you have to always iterate through lists to find your st=
uff, 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 suppo=
rt "big payloads" transparently without passing the burden of the data mana=
gement 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 o=
ne purpose!" let me just say that it's absolutely achievable to have ONE AP=
I for talking userland<->kernel and userland<->userland with the same types=
and the transport mechanism(s) largely abstracted away. You don't need tw=
o - 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 has =
lacked from day one ("just roll your own format and stick the file in /etc"=
being the canonical response to that need).
Interesting.
--=20
Pawel Jakub Dawidek http://www.wheelsystems.com
FreeBSD committer http://www.FreeBSD.org
Am I Evil? Yes, I Am! http://mobter.com
--K8nIJk4ghYZn606h
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (FreeBSD)
iEYEARECAAYFAlHbMD8ACgkQForvXbEpPzRtjwCgx/zgfLEPl6gfbeRWKCsaxUOJ
ILAAnjmBzZEpsfHpeq01R6H9t48HOmNi
=2Q/y
-----END PGP SIGNATURE-----
--K8nIJk4ghYZn606h--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130708213351.GB1405>