Re: The lamentation of proplib(3)

2014-01-28 Thread David Holland
On Tue, Jan 28, 2014 at 09:02:43PM +0100, Jean-Yves Migeon wrote: > Replacement ain't that easy, proplib(3) is used throughout the tree > in multiple places, and they are parts where a full-scale > replacement is not trivial (quotas for one). Quotas don't use proplib. All the quota proplib stuf

Re: The lamentation of proplib(3)

2014-01-28 Thread Mindaugas Rasiukevicius
Taylor R Campbell wrote: >>If you have taken a look at the manual page and the examples section, >>the API is straightforward. I do not think that we all need to hold >> our hands and learn together that prop_dictionary_create() would be >> replaced with nvlist_create(), prop_dictionary_s

Re: The lamentation of proplib(3)

2014-01-28 Thread Mindaugas Rasiukevicius
Jean-Yves Migeon wrote: > >> Secondly, they are tons of interchange formats out there. libnv is one > >> more, with its original author stating that it is not really meant as a > >> replacement for XML/JSON. > > > > The library provides an interface to pack and transport the data. As > > far as t

Re: The lamentation of proplib(3)

2014-01-28 Thread Taylor R Campbell
Date: Tue, 28 Jan 2014 23:22:16 +0100 From: Matthias Kretschmer On Tue, Jan 28, 2014 at 09:36:48PM +, Taylor R Campbell wrote: > I'm inclined to say we ought to use protocol buffers -- it supports > C-enforceable schemas, has been widely adopted in the world, and > satisfies

Re: The lamentation of proplib(3)

2014-01-28 Thread Taylor R Campbell
Date: Tue, 28 Jan 2014 22:37:12 + From: Mindaugas Rasiukevicius If you have taken a look at the manual page and the examples section, the API is straightforward. I do not think that we all need to hold our hands and learn together that prop_dictionary_create() would be replace

Re: The lamentation of proplib(3)

2014-01-28 Thread Jean-Yves Migeon
Le 28/01/2014 22:16, Mindaugas Rasiukevicius a écrit : The long term objective would be to replace and eliminate proplib(3) from the tree. The short to medium term objective is to provide an alternative, start using it and gradually convert proplib uses. Yes, we will need to add compatibility c

Re: The lamentation of proplib(3)

2014-01-28 Thread Mindaugas Rasiukevicius
Taylor R Campbell wrote: > I don't think there's much disagreement that proplib is wrong, but a > proposal to replace it ought to include concrete examples of how > current uses of proplib (or C structs or other wire data transmission > formats) should be replaced, not just general murmuring that

Re: The lamentation of proplib(3)

2014-01-28 Thread Matthias Kretschmer
On Tue, Jan 28, 2014 at 09:36:48PM +, Taylor R Campbell wrote: > I'm inclined to say we ought to use protocol buffers -- it supports > C-enforceable schemas, has been widely adopted in the world, and > satisfies more or less all your desiderata. Parts of the wire format > are a little wacky, b

Re: The lamentation of proplib(3)

2014-01-28 Thread Taylor R Campbell
Date: Tue, 28 Jan 2014 18:44:57 + From: Mindaugas Rasiukevicius 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 l

Re: The lamentation of proplib(3)

2014-01-28 Thread Mindaugas Rasiukevicius
Jean-Yves Migeon wrote: > I agree on the ugliness/impracticality of proplib(3), and got myself > bitten twice. So I am all for alternatives. > > Firstly, one clarification: is your intent to /replace/ proplib(3) or to > /provide/ a simpler interchange format for userland/kernel, and keep > pro

Re: The lamentation of proplib(3)

2014-01-28 Thread John Nemeth
On Jan 28, 7:40pm, Christian Koch wrote: } On Tue, Jan 28, 2014 at 06:44:57PM +, Mindaugas Rasiukevicius wrote: } > 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 s

Re: The lamentation of proplib(3)

2014-01-28 Thread Maxime Villard
Le 28/01/2014 19:44, Mindaugas Rasiukevicius a écrit : > [...] > > - Last but not least, it does not have awkward API naming, such as > prop_data_create_data_nocopy() or prop_number_unsigned_integer_value(). I particularly agree on this one, hehe

Re: The lamentation of proplib(3)

2014-01-28 Thread Jean-Yves Migeon
Le 28/01/2014 19:44, Mindaugas Rasiukevicius a écrit : Hello, Hi, 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

Re: The lamentation of proplib(3)

2014-01-28 Thread Christian Koch
On Tue, Jan 28, 2014 at 06:44:57PM +, Mindaugas Rasiukevicius wrote: > 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 lamentation of proplib(3)

2014-01-28 Thread Mindaugas Rasiukevicius
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 scrat