Date: Fri, 26 Jul 2013 00:15:17 +0200 From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: Steve Kiernan <stevek@juniper.net> Cc: arch@freebsd.org, Jordan Hubbard <jkh@mail.turbofuzz.com> Subject: Re: General purpose library for name/value pairs. Message-ID: <20130725221517.GH1400@garage.freebsd.pl> In-Reply-To: <20130716180606.55ec081c@stevek-ubuntu> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
--ZYOWEO2dMm2Af3e3
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Jul 16, 2013 at 06:06:06PM -0400, Steve Kiernan wrote:
> 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> 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 lis=
t 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 ove=
r the long term, and you can always provide explicit conversion functions t=
o/from Number for those who actually care.
> >=20
> > String, Number, Boolean, Data, Date, Array and Dictionary are all plist=
s support, and Apple developers have gotten along pretty well for many year=
s 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 al=
so added out-of-band types like file and shared memory descriptors. You ha=
ve file descriptors, but not shared memory. The latter is kind of importan=
t if you want to do larger IPCs with this mechanism someday and want to sup=
port "big payloads" transparently without passing the burden of the data ma=
nagement to the application programmer.
> >=20
> > 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 typ=
es 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 t=
he dictionary type) , bingo, now you have a preferences API that FreeBSD ha=
s lacked from day one ("just roll your own format and stick the file in /et=
c" being the canonical response to that need).
>=20
> What about looking at NetBSD's libprop?
Someone already suggested that, but libprop is much much more complex
than libnv. I really want something extremely easy to use, so it can
be adopted quickly.
--=20
Pawel Jakub Dawidek http://www.wheelsystems.com
FreeBSD committer http://www.FreeBSD.org
Am I Evil? Yes, I Am! http://mobter.com
--ZYOWEO2dMm2Af3e3
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (FreeBSD)
iEYEARECAAYFAlHxo3UACgkQForvXbEpPzT6cQCfVNm1+zYwgeZRETQqvZgBHgrC
+gAAmwdX6e7K/l3AfSaYUXtFUqT27+KR
=6OOn
-----END PGP SIGNATURE-----
--ZYOWEO2dMm2Af3e3--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130725221517.GH1400>