linuxaudio.org

2011/2/25 David Robillard :

quoted text
> 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.
Stefano

_______________________________________________

Linux-audio-dev mailing list

Linux-audio-dev@lists.linuxaudio.org

http://lists.linuxaudio.org/listinfo/linux-audio-dev