bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Gauge interest in an XDR implementation


From: Bruno Haible
Subject: Re: Gauge interest in an XDR implementation
Date: Wed, 5 Nov 2008 02:03:06 +0100
User-agent: KMail/1.5.4

Richard W.M. Jones wrote:

> > I'd like to know whether Gnulib developers would be interested in
> > taking on an XDR implementation (based on the one in glibc)?

Yes, this definitely can have its place in gnulib, because it is glibc
functionality that is not present on all other systems. You can look at
the files doc/glibc-functions/xdr*.texi to get a feeling of it. As Richard
said, many systems lack functions such as xdr_uint64_t.

Whether you actually want it in gnulib, or add only hooks to gnulib so
that it can use portableXDR when it is installed, is up to you. libintl
and libiconv are in a similar situation: they implement functionality
that is in glibc but not in other systems. But because of their size
and self-containedness, it is better to distribute them as libintl.so and
libiconv.so, rather than to include the source code in every program that
needs it.

> The request brings up the issue of what the limits of what can be in
> gnulib.  I'm not sure it is a useful discussion...

My opinion: If it's "common" in the sense that more than one GNU package
is likely to use the code, it's welcome in gnulib. And if it's a collection
of small codes, rather than a big atomic chunk of code, it also technically
makes sense to have it in gnulib.

> Anyway, for example,
> libtasn1 is used by GnuTLS, Shishi, and probably some other projects as
> well, and I have thought about proposing parts of it as gnulib modules.
> Probably the only reason I haven't done so already is because the code
> is quite hard to read and maintain.

Does it make more sense to have these packages installed as shared libraries,
rather than shipped and linked into every application that needs it?

Bruno





reply via email to

[Prev in Thread] Current Thread [Next in Thread]