On Thu, Mar 04, 2004 at 07:34:48 +0100, Fons Adriaensen wrote:
On Thu, Mar 04, 2004 at 04:48:09PM +0000, Steve Harris
wrote:
On Thu, Mar 04, 2004 at 04:59:31 +0100, Alfons
Adriaensen wrote:
I had a look at the TAP RDF file, and compared
the useful contents to the
file lenght. The ratio of these two puts RDF in the 'bloated' category.
And it's not easy to read or write at all.
It is not a problem if you use a library.
That doesn't make it less bloated :-)
Hmmm... bloat is relative - the description of all the TAP, CMT and SWH
(> 100) plugins on my system + the schema takes up 200k on disk - which is
only 12k if you gzip it (you can keep it gzipped on disk if you like), in
lrdf's in-memory form thats something like 20k of ram.
c.f. the difference between writing your software in C over C++ ;)
To me this is a mess. It should be perfectly possible
to extend the port
descriptors in such a way that things like preset names, scale ticks,
units etc. are available from there.
It would be, but its hard to keep binary compatibility and wouldnt it be
better to just have one extensible metadata format that you can use for
ports descriptions, scales, defaults, and presets?
Well, you don't expect the host to compile and link the source code (this
should be perfectly possible of course). If it gets the code in a compiled
form that can (almost) be directly executed, why not do the same for the
all the data it needs ?
I dont follow this point.
And if a second (text) file is used, I'd much
prefer something simpler than
XML. A good candidate could be OSC for example. Any command language can be
used for configuration as well.
OSC is not simpler than XML. Really. Also, it doesnt have the features
you'd want for metadata representation, so you end up re-inventing much of
RDF, but with a syntax and semnatics that no-one else could understand.
In any case XML is not the only RDF syntax, the one lrdf uses for export
(eg. if you save a preset out) is Ntriples, which is basicly:
<a:foo> <a:bar> "some value" .
...
Doesnt get much easier than that.
- Steve