On Wed, Jan 29, 2014 at 03:05:41AM +, Mindaugas Rasiukevicius wrote:
In this case, the proplib implementation has such major deficiencies that
replacing it itself is a virtue. Fixing is not the case here, as it would
basically mean rewriting.
Since this thread has died down again, here
On Fri, Feb 07, 2014 at 06:28:59PM +, David Holland wrote:
(1) It seems the consensus over the last 5+ years is that the library
we want is a data transfer library, not a data storage library. If you
want the latter, we have libdb and sqlite.
Agreed, but please avoid db(3) :)
(2) We
On Tue, 28 Jan 2014 21:36:48 +
Taylor R Campbell campbell+netbsd-tech-k...@mumble.net wrote:
libnv may be more type-safe as an API itself than proplib, but if we
are going to seriously adopt something for formal protocols, it ought
to have schemas that support enforcement in the C type
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
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.
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.
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
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
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, but
Taylor R Campbell campbell+netbsd-tech-k...@mumble.net 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,
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
Taylor R Campbell campbell+netbsd-tech-k...@mumble.net 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
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 stuff
13 matches
Mail list logo
