Date: Thu, 25 Apr 2013 00:15:53 -0400 From: Rich Felker <dalias@...ifal.cx> To: musl@...ts.openwall.com Subject: High-priority library replacements? Hi all, 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. I don't think I'll be the one to do them, but I wouldn't mind overseeing/mentoring someone working on them, or just getting somebody else interested in these projects. A few initial ideas: 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. 2. SSL. The modern internet basically requires using SSL everywhere. We should be aiming/expecting to transition to a world where even non-login-based sites are 100% https; the threats of malicious http injection attacks from rogue or advertising-based access points has gotten too great. 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. It should also be able to keep up with the changing demands of how to determine which certificate authorities are to be trusted. 3. Image format and compression (libpng, zlib, etc.). The existing libraries are full of atrociously bad error-handling practices, and quite bloated. These libraries should be well-factored so that programs that just want to read (the majority of use cases) don't have to pull in code for writing. Unfortunately the interfaces might not be so simple, since an important usage case is progressive rendering of partially-loaded images, both for the purpose of loading over slow network connections and for rendering thumbnails quickly. All of these libraries should: - Avoid namespace pollution. Only external symbols should be the public API and internal-use stuff prefixed with an ugly prefix that's extremely unlikely to clash with anything. - Avoid unnecessary allocation. Use caller-provided objects where possible or provide both options. - Have absolutely zero global state. 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. Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.