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

On 02/25/2011 09:13 PM, Stefano D'Angelo wrote: Size. There are two bottlenecks related to size when deploying on Android: - the space it takes on the device. In the past apps could only be installed in the device internal memory, and it is often quite small, like about 150Mb. People tend to install a lot of apps so this gets filled quickly. So, a mechanism, app2sd, has been added to allow installing apps on the sdcard, which is usually more than 8Gb. But this doesn't work for native libraries, because the sdcard is mounted noexec. You can use app2sd, but the native libraries provided by the app are copied to internal memory. - the download time. It is common for users to download apps when they're on the go, and thus possibly using a bad internet link. My app is currently a little less than 1Mb, and I actually don't really want to make it bigger. Some games can get big, but my app isn't a game, it's intended to be lightweight. For example, I needed to add a little magic, to detect file formats. So I grabbed libmagic, compiled that, linked statically, and IIRC it resulted in a size increase of about 200Kb. That was quite unacceptable for such a simple functionality. So, I read the code and libmagic metadata files, and I implemented my own magic (OGG, WAV, FLAC, AIFF, MP3) in about 30 lines of C. I had a couple of bugs, but it now works flawlessly. That said, I would need to test what kind of size it takes when linking statically against SLV2. But I will need to support glib as a shared library or something like that because of the LGPL. That's a lot of complication. This RDF turtle format is surely a beautiful thing when you write or read it, but it requires such a parsing machinery... What about an alternative format intended for lightweight packaging and parsing? It would take the turtle metadata and convert it into a text file which could be parsed with about 100 lines of C. It may not work for all plugins, but maybe for the vast majority of them? At least I'm thinking about that kind of solution for packaging for Android. Some kind of pre-parsing/metadata-simplification at packaging stage to avoid the need for bundling a full-fledged parser.