7 Jun
2008
7 Jun
'08
11:32 p.m.
Hello,
First of all I want to announce that the next version of NASPRO will
shift to LV2 as its internal model, which means that it will contain a
collection of bridges from other APIs to LV2 and viceversa
In order to accomplish such a thing (writing wrappers for LV2), a
special extension is needed to make the host call some function in a
shared object file to generate a new manifest.ttl-like file (possibly
using tmpfile() or similar). The host will call this function and read
the file to know about bridged plugins.
Now, I wrote something (taking "inspiration" from other extensions,
etc.), but since I'm a total beginner with RDF and LV2, please someone
check whether the following stuff is correct.
lv2_dyn_manifest.ttl:
@prefix : <http://naspro.atheme.org/ext/dyn-manifest#> .
@prefix lv2: <http://lv2plug.in/ns/lv2core#> .
@prefix dman: <http://naspro.atheme.org/ext/dyn-manifest#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix doap: <http://usefulinc.com/ns/doap#> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
<http://naspro.atheme.org/ext/dyn-manifest#> a lv2:Specification ;
doap:license <http://usefulinc.com/doap/licenses/bsd> ;
doap:name "LV2 Dynamic Manifest" ;
rdfs:comment "" ;
doap:mainainer [
a foaf:Person ;
foaf:name "Stefano D'Angelo" ;
foaf:homepage <http://zanga.netsons.org/>
] .
:DynManifest a rdfs:Class ;
rdfs:label "Dynamic Manifest" ;
rdfs:comment """
The class which represents a dynamic generator of a manifest.ttl-like file.
""" .
lv2_dyn_manifest.h:
#ifndef LV2_DYN_MANIFEST_H_INCLUDED
#define LV2_DYN_MANIFEST_H_INCLUDED
#include <stdio.h>
/* This function shall create a temporary file containing the dynamically
* generated manifest.ttl-like file and return a FILE pointer or NULL in case
* of failure.
*
* The generated file must not implement DynManifest classes. */
FILE * lv2_dyn_manifest();
#endif /* LV2_DYN_MANIFEST_H_INCLUDED */
I hope this is enough since I'm guessing that manifest.ttl can also
contain plugin-related information (the LV2 wiki suggests using
separate files, but maybe it's possible/valid nonetheless).
Then, some kind of API property could be associated to a plugin class
to indicate the original plugin API (needs an extensions or
something?).
In the end, I'm using FILE * because of file locking + standard C
library. If anyone is against that, please say so (with motivations).
Thanks in advance,
Stefano