On 02/26/2011 07:07 PM, David Robillard wrote:
On Sat, 2011-02-26 at 17:33 +0100, Olivier Guilyardi
wrote:
[...]
This RDF turtle format is surely a beautiful
thing when you write or read it,
but it requires such a parsing machinery...
The serd reader is about 1300 lines of C with no dependencies.
Sounds good.
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?
If you want a /really/ simple to parse RDF text format, it's ntriples.
The actual data itself would become significantly larger than the space
you save in the parsing code. I doubt this would be a net space savings,
unless very few plugins are involved. You could gzip it or something,
but then the plugin format is broken/wierd and you need even more
machinery...
libserd.so is 34K on my 64-bit machine (compiled with -Os), and that
includes an abbreviating serialiser. If you stripped it down to the
reader it would be significantly smaller still (let's say halved).
I don't get it. Do you mean that libserd is the only thing that I would need in
the host?
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.
Is that "full-fledged" parser really too big? You can't spend ~20K in a
program that's loading plugins and doing audio processing? Let's keep
things in perspective here: this parser is about as large as a simple
plugin or two, and certainly smaller than some. I don't think claiming
this is an unacceptable implementation size for using those plugins is
at all reasonable. The heavyweight parsing machinery problem is a thing
of the past.
20K? Now we're talking :)
But I don't understand exactly what's required in the host and also during
packaging to achieve such a tiny requirement.
--
Olivier