From 430284545345539c9ffb31df889debac1d3888b5 Mon Sep 17 00:00:00 2001 From: David Robillard Date: Sun, 22 Mar 2020 16:36:44 +0100 Subject: Move documentation to metadata files and convert it to Markdown --- lv2/dynmanifest/dynmanifest.meta.ttl | 79 +++++++++++++++++++++++++++++++++++- lv2/dynmanifest/dynmanifest.ttl | 71 +++----------------------------- 2 files changed, 82 insertions(+), 68 deletions(-) (limited to 'lv2/dynmanifest') diff --git a/lv2/dynmanifest/dynmanifest.meta.ttl b/lv2/dynmanifest/dynmanifest.meta.ttl index 77f03ca..7527494 100644 --- a/lv2/dynmanifest/dynmanifest.meta.ttl +++ b/lv2/dynmanifest/dynmanifest.meta.ttl @@ -1,6 +1,8 @@ @prefix dcs: . +@prefix dman: . @prefix doap: . @prefix foaf: . +@prefix lv2: . @prefix rdfs: . @@ -9,7 +11,7 @@ doap:name "LV2 Dynamic Manifest" ; doap:homepage ; doap:created "2009-06-13" ; - doap:shortdesc "Support for dynamic data generation." ; + doap:shortdesc "Support for dynamic manifest data generation." ; doap:programming-language "C" ; doap:developer ; doap:release [ @@ -52,5 +54,78 @@ rdfs:label "Initial release." ] ] - ] . + ] ; + 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: + + :::turtle + + a dman:DynManifest ; + lv2:binary . + +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 + +To access data using this API, the host must: + + 1. Call lv2_dyn_manifest_open(). + + 2. Create a `FILE` for functions to write data to (for example with `tmpfile()`). + + 3. Get a list of exposed subject URIs using lv2_dyn_manifest_get_subjects(). + + 4. Call lv2_dyn_manifest_get_data() for each URI of interest to write the + related data to the file. + + 5. Call lv2_dyn_manifest_close(). + + 6. Parse the content of the file(s). + + 7. Remove the file(s). + +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. + + +"""^^lv2:Markdown . + +dman:DynManifest + lv2:documentation """ + +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). + +"""^^lv2:Markdown . diff --git a/lv2/dynmanifest/dynmanifest.ttl b/lv2/dynmanifest/dynmanifest.ttl index caa2a08..c93120f 100644 --- a/lv2/dynmanifest/dynmanifest.ttl +++ b/lv2/dynmanifest/dynmanifest.ttl @@ -7,67 +7,10 @@ a lv2:Specification ; + rdfs:label "LV2 Dyn Manifest" ; + rdfs:comment "Support for dynamic manifest data generation." ; 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 ; @@ -76,11 +19,7 @@ dman:DynManifest 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 "A DynManifest MUST have at least one lv2:binary." ] ; - 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).""" . + rdfs:comment "Dynamic manifest for an LV2 binary." . -- cgit v1.2.1