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

[Olivier Guilyardi]

On 02/25/2011 09:13 PM, Stefano D'Angelo wrote:
> 2011/2/25 Olivier Guilyardi <list at samalyse.com>:

>> That said there is another big problem. This glib dependency, it's way too heavy
>> for mobile deployment.
> 
> Since this was already discussed and we happen to have possible GLib
> replacements, could you expand on that? Why is it too heavy?

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.

--
  Olivier