Re: High-priority library replacements?

[LM <lmemsm@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 5668 bytes --]

On Thu, Apr 25, 2013 at 12:15 AM, Rich Felker <dalias@aerifal.cx> wrote:

> The recent thread "Best place to discuss other lightweight libraries"
> had me thinking we should really put together a list of high-priority
> library replacements that need to be done.
>

Sounds like a great idea.


> 1. A light, C, UTF-8-only Unicode library. The most important things
> it should implement are things needed by any application that presents
> text to the user, specifically line-breaking (UAX#14), bidi (UAX#9),
> identifying grapheme clusters, etc. Things like case- and
> normalization-insensitive comparison, application of Unicode-format
> collation rules, etc. would also possibly be useful.
>

I have something I'm working on that I'm using for my sdcv port.  It mainly
covers things like switching from utf8 to uint32_t and back and utf8
equivalents of isspace, isdigit, toupper, tolower, etc.  I really like the
Plan 9 rune implementation.  I didn't need all the functionality of the
Plan 9 library, so I'm creating a small library with just the minimal
functions I need.  If you check Ohloh, I've also seen some examples of
internationalized versions of standard functions like isdigit, isspace
there.


>
> 2. SSL.

...

> Unfortunately, all of the existing SSL
> implementations are bloated, buggy, and fail even the most basic
> robustness requirements. A good solution would be based on tomcrypt
> and would expose a minimal, simple API suited for event-loop-based or
> threaded use. It may also be useful to have an optional wrapper layer
> to expose an API that mimics openssl or gnutls.


I think an openssl wrapper and possibly a gnutls one would be essential if
you want to have it work with all the Open Source programs already out
there.

There are three main options I currently know about: openssl, gnutls, and
nss.  Each has a different license.  So depending on how a program is
licensed, you may not legally be able to use some of these libraries with
the program.  Any GNU licensed program requires an optional waiver to link
with openssl.  You find many Open Source programs provide the optional
waiver.  One really good example of the license issue concerns lynx.  You
can check their mailing list for a detailed discussion.  The highlights are
that lynx is GPLv2 and the project can't contact all the authors who worked
on it to change the license or get a waiver for linking to other types of
incompatible licenses.  The openssl library can't be used with a GNU
program unless there's a waiver for it because one of the clauses in the
openssl license goes against the GNU license principles.  The gnutls
openssl compatibility wrapper is GPL v3, so it can't be used unless the
program is relicensed at GPL v3 (
http://www.gnu.org/licenses/gpl-faq.html#AllCompatibility ).  That just
leaves nss licensed under MPL, LGPL and/or GPL.  If it's LGPL, lynx can use
it.

Moral of the story, if anything's going to be done to replace these
libraries, it would have to be under appropriate license(s) or one would
not be able to use the results with existing Open Source software already
out there without violating copyright.

 3. Image format and compression (libpng, zlib, etc.).
>

A good SVG library is needed.  To get SVG into Tuxpaint, it added libcroco,
librsvg2, libcairo and other GTK+ library dependencies.  Tuxpaint is based
on SDL, so would prefer not to see all the added code for two GUI
libraries.  Someone was recently asking on the SDL list about SVG library
options that are actively supported.  The only one with active  support
that I could locate (besides librsvg2) was the one used by netsurf (
http://www.netsurf-browser.org/projects/libsvgtiny/ ).

If you're looking at graphics formats.  You might as well add audio formats
to the list too.  There are a wide variety of libraries for the different
audio formats and they range in quality (and license types).


> That's all I can think of at the moment but I'm sure there are other
> needs I've come across and forgotten. Please feel free to supplement
> this list.
>
>
As already mentioned, libintl is on my list of things to replace if
possible.  pkg-config has a nice replacement in pkgconf.  (If a list is
created, might be helpful to list possible replacements already out
there.)  Would like to see some of the pieces that are essential parts of
the GNU build system/autotools replaced with some more efficient
alternatives.  It's easier to keep using the GNU autotools system than to
completely replace it with a new design.  Replacing it with another system
completely would mean switching over any program or library one wants to
build from the many Open Source programs already out there that currently
use it.  The CoApp project is attempting to do that on Windows (switch
other build systems over to the one used by Visual C++).  Seems like a lot
of unnecessary work to port applications.  Would rather see the current
build systems already used (autotools, cmake, etc.) streamlined or see drop
in replacements that are better designed.

One other area that can be troublesome is when there are multiple libraries
with similar functionality and some of the programs you want to build use
one while the rest use another.  The openssl/gnutls/nss example is an
issue.  It's typically solved by supplying wrapper interfaces.  The case I
keep running into at the moment is libxml2/expat.  libxml2 is newer and
works in conjunction with libraries like libxslt.  Some Open Source
programs let you pick one or the other.  Unfortunately, there are some that
insist on only one.  Makes it hard to simplify one's system down to just
using one XML library.

Sincerely,
Laura

[-- Attachment #2: Type: text/html, Size: 6927 bytes --]