From 4db67120efca2d4c200d2e1ba5cf3d7b97cab97e Mon Sep 17 00:00:00 2001 From: David Robillard Date: Sat, 22 Sep 2018 20:38:01 +0200 Subject: Install standard headers to simpler include paths --- lv2/lv2plug.in/ns/ext/dynmanifest/dynmanifest.ttl | 85 ----------------------- 1 file changed, 85 deletions(-) delete mode 100644 lv2/lv2plug.in/ns/ext/dynmanifest/dynmanifest.ttl (limited to 'lv2/lv2plug.in/ns/ext/dynmanifest/dynmanifest.ttl') diff --git a/lv2/lv2plug.in/ns/ext/dynmanifest/dynmanifest.ttl b/lv2/lv2plug.in/ns/ext/dynmanifest/dynmanifest.ttl deleted file mode 100644 index 63e0730..0000000 --- a/lv2/lv2plug.in/ns/ext/dynmanifest/dynmanifest.ttl +++ /dev/null @@ -1,85 +0,0 @@ -@prefix dman: . -@prefix lv2: . -@prefix owl: . -@prefix rdf: . -@prefix rdfs: . -@prefix xsd: . - - - a lv2:Specification ; - rdfs:seeAlso , - ; - lv2:documentation """ -

The LV2 API, on its own, cannot be used to write plugin libraries where data -is dynamically generated at runtime (e.g. API wrappers), since LV2 requires -needed information to be provided in one or more static data (RDF) files. This -API addresses this limitation by extending the LV2 API.

- -

To detect that a plugin library implements a dynamic manifest generator, -the host checks its static manifest for a description like:

- -
-<http://example.org/my-dynamic-manifest>
-    a dman:DynManifest ;
-    lv2:binary <mydynmanifest.so> .
-
- -

To load the data, the host loads the library -(e.g. mydynmanifest.so) as usual and fetches the dynamic Turtle -data from it using this API.

- -

The host is allowed to request regeneration of the dynamic manifest multiple -times, and the plugin library is expected to provide updated data if/when -possible. All data and references provided via this API before the last -regeneration of the dynamic manifest is to be considered invalid by the host, -including plugin descriptors whose URIs were discovered using this API.

- -

Accessing Data

- -

Whenever a host wants to access data using this API, it could:

- -
    -
  1. Call lv2_dyn_manifest_open().
    2. -
  2. Create a FILE for functions to write data to (e.g. using tmpfile()).
    3. -
  3. Get a list of exposed subject URIs using - lv2_dyn_manifest_get_subjects().
    4. -
  4. Call lv2_dyn_manifest_get_data() for each URI of interest to - get the data related to that URI (which can be written to any FILE).
    5. -
  5. Call lv2_dyn_manifest_close().
    6. -
  6. Parse the content of the FILE(s).
    7. -
  7. Free/delete/unlink the FILE(s).
    8. -
- -

Each call to the above mentioned dynamic manifest functions MUST write a -complete, valid Turtle document (including all needed prefix definitions) to -the output FILE.

- -

Each call to lv2_dyn_manifest_open() causes the (re)generation of the -dynamic manifest data, and invalidates all data fetched before the call.

- -

In case the plugin library uses this same API to access other dynamic -manifests, it MUST implement some mechanism to avoid potentially endless loops -(such as A loads B, B loads A, etc.) and, in case such a loop is detected, the -operation MUST fail. For this purpose, use of a static boolean flag is -suggested.

- -

Threading Rules

- -

All of the functions defined by this specification belong to the Discovery -class.

-""" . - -dman:DynManifest - a rdfs:Class ; - rdfs:label "Dynamic Manifest" ; - rdfs:subClassOf [ - a owl:Restriction ; - owl:onProperty lv2:binary ; - owl:minCardinality 1 ; - rdfs:comment "A DynManifest MUST have at least 1 lv2:binary, which MUST implement all the functions defined in dynmanifest.h." - ] ; - rdfs:comment """The class which represents a dynamic manifest generator. - -There MUST NOT be any instances of dman:DynManifest in the generated manifest. - -All relative URIs in the generated data MUST be relative to the base path that would be used to parse a normal LV2 manifest (the bundle path).""" . -- cgit v1.2.1