linuxaudio.org

2011/2/26 Stefano D'Angelo :

quoted text
> 2011/2/25 David Robillard :

>> 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

Oops, I meant, to replace GLib in SLV2.
Stefano

_______________________________________________

Linux-audio-dev mailing list

Linux-audio-dev@lists.linuxaudio.org

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