[LAD] LV2 dyanic manifest extension proposal

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
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Sun Jun 8 08:15:02 2008