The lamentation of proplib(3)

[Mindaugas Rasiukevicius <rmind%netbsd.org@localhost>]

Hello,

Many developers have been dissatisfied with proplib(3) for quite a while
and my own dissatisfaction has reached the point where I decided to raise
the question.  The question of replacing proplib(3) with a better library.
There were ideas by some developers to write a new library from scratch.
The FreeBSD project has recently developed a general purpose key-value pair
library, which is quite similar to nvpair library in Solaris.

See [1] for discussion on freebsd-arch@, [2] for the source code and [3]
for the manual page describing the API.  The library looks still a work
in progress, however from a quick review of the code - it seems to be a
reasonable candidate to start.

Why replace proplib with libnv?  Because contrary to proplib:
- It provides the equivalent functionality, but with twice less code.
- It does not have insane reference counting like proplib (particularly,
  asymmetric prop_dictionary_get() and prop_dictionary_set() routines).
- It does not use inefficient XML-like format.  It is binary.
- It does not add locking overhead which you do not need, see PR/44094.
- It does not have shared structures, e.g. proplib stores the keys in a
  global red-black tree (besides the fact that its implementation is
  duplicated, see PR/44090).  That means for example that the contention
  on one subsystem can negatively affect another, unrelated, subsystem!
- It does not abuse void * and therefore has more type safe code.
- It supports accumulated error handling (relevant for most use cases).
- Last but not least, it does not have awkward API naming, such as
  prop_data_create_data_nocopy() or prop_number_unsigned_integer_value().

This list is not finite, but should cover the essential points.

Note that libnv is meant to be lightweight.  That is an important aspect
as I would like to see the library which focuses on data serialisation
and transportation, rather than data storage, fancy processing or other
features which are not meant to be in such library.  We may add schema
support (without going towards XDR 2.0) and extra serialisation formats,
but that is about it.

Discuss.


[1] http://lists.freebsd.org/pipermail/freebsd-arch/2013-July/014464.html
[2] http://nxr.netbsd.org/xref/src-freebsd/lib/libnv/
[3] http://www.freebsd.org/cgi/man.cgi?query=nv&manpath=FreeBSD+11-current

-- 
Mindaugas