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. -dr _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
