Re: libnv

[Jason Thorpe <thorpej%me.com@localhost>]

> On Aug 27, 2018, at 7:49 AM, Mindaugas Rasiukevicius <rmind%netbsd.org@localhost> wrote:

> I do not think there was any conclusion either, or a conclusion that
> we always want to have static serialisation with a schema (IMO, there
> are pros and cons in both cases).  Worth noting that there are multiple
> libraries already: we already imported libnvpair (with tons of other
> code for ZFS and DTrace) and nobody complained; we still have XDR.

XDR has a separate reason for existing -- it is enshrined in wire protocols.

> While libnv is not a panacea, it solves some actual problems: it has
> intuitive reference counting (symmetric API), it supports accumulated
> error handling, it provides more efficient binary encoding, it does not
> have shared structures with internal locking, it does not have awkward
> API.  As a side note, it also makes code sharing with FreeBSD (as well
> as illumos) much easier.  Meanwhile, there has been little action on
> improving proplib or proposing a tangible replacement of it.

Let me try to address these points one by one:

==> It has intuitive reference counting (symmetric API)

I just sent you a separate mail on this subject.  Actually, the libprop reference counting rules are very simple:

"If you create an object, you implicitly own the reference and you are responsible for disposing of it.  In all other cases, references must be explicitly retained."

That's it.  It's really not that complicated.  Containers (arrays and dictionaries) retain their own references explicitly (because they want the object the live on not matter what the caller does with its own reference).  When you "get" an object from the container, you did not create it, and thus need to explicitly retain your own (that you, of course, are responsible for disposing of later).

Please explain to me how this referencing counting rule is non-intuitive.


==> It supports accumulated error handling

I personally find APIs like this kind of annoying, but if you find it valuable, it could be added to libprop with a utility wrapper API.


==> It provides more efficient binary encoding

I'll grant this one, but with a caveat -- I always intended to to add the "binary plist" serialization format to libprop, but never got around to it.  It would require a refactor of the serialization stuff that's already in libprop, but this is a solvable problem and have been thinking of doing it soonish anyway because of some other ideas I've been toying with in my head.


==> It does not have shared structures with internal locking

I'll grant that this was probably a mistake initially with dictionaries and arrays.  Serialization for these should be handled at the caller's level, because in many instances you would need that anyway if you expect multiple threads to be accessing the container (to provide correct semantics at the caller's layer).  So, as such, it would probably be worth having a discussion about whether removing the internal locking would be a safe thing to do.


==> It does not have an awkward API

The individual object APIs themselves can be kind of awkward to use, but that was the price to pay for flexibility.  There are already several utility APIs that provide a simpler interface, and those could be extended.




> 
> Anyway, I am not proposing that everybody should use libnv.  However,
> it is is quite lightweight and self-contained.  I am already using libnv
> in the upstream NPF.  The conversion to libnv made the code simpler,
> shorter and easier to read.  And I am not planning to maintain proplib
> version: it causes too much headache and the differences are too vast.
> 
> -- 
> Mindaugas

-- thorpej