[LAD] RDF libraries, was Re: [ANN] IR: LV2 Convolution Reverb

[Stefano D'Angelo]

2011/2/26 David Robillard <d at drobilla.net>:
> On Sat, 2011-02-26 at 15:11 +0100, Stefano D'Angelo wrote:
>> 2011/2/25 David Robillard <d at drobilla.net>:
>> > On Fri, 2011-02-25 at 21:09 +0100, Olivier Guilyardi wrote:
>> >> On 02/25/2011 08:57 PM, David Robillard wrote:
>> >>
>> >> >> It's a few months ago now that I investigated LV2. IIRC, at that time I
>> >> >> concluded that this wasn't an option because SLV2 was GPL'ed. But things are
>> >> >> changing IIUC :)
>> >> >
>> >> > You never asked. I would have changed it... but I am not psychic ;)
>> >>
>> >> It's not always easy to discuss about religious matters, such as licenses ;)
>> >>
>> >> That said there is another big problem. This glib dependency, it's way too heavy
>> >> for mobile deployment.
>> >
>> > Glib was the most effective route of getting the job done - rewriting
>> > the few bits that are required is not an effective use of my time right
>> > now (it's not exposed in the API, so it's not a compatibility issue, and
>> > there's a ton of more pressing LV2 things that need doing).
>> >
>> > I'm not a huge fan of wheel-reinventing, and on PCs glib is about as
>> > unoffensive a dependency as they come. On mobile, I guess that meg or so
>> > actually makes a difference.
>> >
>> > Replacing glib will not be very difficult, very little of it is used:
>> > just a balanced BST, dynamic array, and ideally a hash table or trie
>> > other appropriate structure for string interning (the BST would do for
>> > this part, with a bit of a performance cost). Good old-fashioned data
>> > structure implementation is my favourite thing to do, but unfortunately
>> > there is no shortage of more pragmatic things that need doing ;)
>> >
>> > Perhaps Stefano's NASPRO core work will do, or using C++ internally, or
>> > just tearing the required bits out of glib itself. Sqlite has an
>> > in-memory hash table IIRC. Code abounds.
>> >
>> > Present a viable alternative, and I'll switch sord/slv2 to it, but I
>> > have no good reason to invest time in reinventing glib right now.
>>
>> Given the discussions we had already, NASPRO core could be a viable alternative.
>>
>> Pros:
>> - no dependencies apart from libc and libm
>> - size (181K without stripping on Arch Linux x86-64, -O2)
>> - high portability, little and confined platform-specific code,
>> compiler-specific (symbol visibility, etc.) code confined to a small
>> header
>> - gracefully handles platform-specific conventions (i.e., ':' vs ';'
>> in path variables, zero-length prefixes in path variables under *nix,
>> directory separators, etc.)
>> - total amount of code is circa 7.5k lines, including comments and
>> public headers
>> - UTF-8 support, conversion from/to UTF-16 LE, serious UTF-8 grapheme
>> counting is supported
>> - thread safety (e.g., data types are synchronized at a very granular
>> level, but allow you to have more coarse synchronization if you want)
>> - extremely low memory footprint
>> - locale-independent asprintf() and vasprintf(), C99 level (except
>> "%lc" and "%ls" conversions, possibly they are not even needed if
>> using UTF-8)
>> - semi-serious, integrated and as-lightweight-as-it-can-be
>> error/message reporting mechanism
>> - precise and well defined error checking and error codes
>> - includes directory traversal, dynamic loading
>> - well documented
>>
>> Cons:
>> - not yet released
>> - no real test suite and not extensively tested
>> - currently implemented data types: doubly linked lists and AVL trees only
>> - not yet ported to non POSIX platforms (i.e., Windows)
>> - API/ABI are "stable enough", but can't guarantee for total stability
>> in the next future (i.e., no big changes will happen, yet something
>> might change)
>> - no locale-independent sscanf() or similar
>> - no UTF16-BE support/conversion
>> - till now, a one man effort
>>
>> That is, it is certainly possible to make it become viable to replace
>> SLV2, but this is not high priority for me at the moment. Once the new
>> NASPRO release is out I can consider whether to do the work, since I
>> want to port SLV2 to Windows right after.
>>
>> The decision, however, depends on whether Dave would like that or not.
>
> Sure. Sounds good, probably a good choice, and it would be nice if your
> work - originally intended to escape slv2 - could be used by it to make
> a better general solution instead :)

You got the idea. :-D