From 3dd648663b5d7c469ccedbb2cf521dc466ceadaa Mon Sep 17 00:00:00 2001 From: David Robillard Date: Sat, 19 Nov 2011 22:25:01 +0000 Subject: HTMLify documentation. --- ext/dynmanifest.lv2/dynmanifest.h | 255 +++++++++++++----------------------- ext/dynmanifest.lv2/dynmanifest.ttl | 66 +++++++++- ext/dynmanifest.lv2/manifest.ttl | 6 +- 3 files changed, 157 insertions(+), 170 deletions(-) diff --git a/ext/dynmanifest.lv2/dynmanifest.h b/ext/dynmanifest.lv2/dynmanifest.h index 18b62e2..7c08fb1 100644 --- a/ext/dynmanifest.lv2/dynmanifest.h +++ b/ext/dynmanifest.lv2/dynmanifest.h @@ -1,6 +1,6 @@ /* Dynamic manifest specification for LV2 - Copyright (C) 2008-2011 Stefano D'Angelo + Copyright 2008-2011 Stefano D'Angelo Permission to use, copy, modify, and/or distribute this software for any purpose with or without fee is hereby granted, provided that the above @@ -15,6 +15,13 @@ OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. */ +/** + @file dynmanifest.h + C header for the LV2 Dynamic Manifest extension + . + Revision: 1.1 +*/ + #ifndef LV2_DYN_MANIFEST_H_INCLUDED #define LV2_DYN_MANIFEST_H_INCLUDED @@ -28,177 +35,104 @@ extern "C" { #endif - -/* ************************************************************************* */ - - -/** @file - * C header for the LV2 Dynamic Manifest extension - * . - * Revision: 1.1 - * - * == Overview == - * - * 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. - * - * A host implementing support for this API should first detect that the plugin - * library implements a dynamic manifest generator by examining its static - * manifest file, then fetch data from the shared object file by accessing it as - * usual (e.g., dlopen() and family) and 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. - * - * This API is extensible in a similar fashion as the LV2 API. - * - * == Accessing data == - * - * Whenever a host wants to access data using this API, it could: - * - * -# Call lv2_dyn_manifest_open(); - * -# Create an empty resource identified by a FILE *; - * -# Get a "list" of exposed subject URIs using - * lv2_dyn_manifest_get_subjects(); - * -# Call lv2_dyn_manifest_get_data() for each URI of interest, in order to - * get data related to that URI (either by calling the function subsequently - * with the same FILE * resource, or by creating more FILE * resources to - * perform parallel calls); - * -# Call lv2_dyn_manifest_close(); - * -# Parse the content of the FILE * resource(s). - * -# Free/delete/unlink the FILE * resource(s). - * - * The content of the FILE * resources has to be interpreted by the host as a - * regular file in Turtle syntax. This also means that each FILE * resource - * should also contain needed prefix definitions, in case any are used. - * - * Each call to lv2_dyn_manifest_open() automatically implies the (re)generation - * of the dynamic manifest on the library side. - * - * When such calls are made, data fetched from the involved library using this - * API before such call is to be considered no more valid. - * - * 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. - * - * Extensions to this specification which add new functions MUST declare in - * which classes the functions belong, or define new classes for them. - */ - - -/* ************************************************************************* */ - - -/** Dynamic manifest generator handle. - * - * This handle indicates a particular status of a dynamic manifest generator. - * The host MUST NOT attempt to interpret it and, unlikely LV2_Handle, it is NOT - * even valid to compare this to NULL. The dynamic manifest generator MAY use it - * to reference internal data. */ +/** + Dynamic manifest generator handle. + + This handle indicates a particular status of a dynamic manifest generator. + The host MUST NOT attempt to interpret it and, unlikely LV2_Handle, it is + NOT even valid to compare this to NULL. The dynamic manifest generator MAY + use it to reference internal data. +*/ typedef void * LV2_Dyn_Manifest_Handle; - -/* ************************************************************************* */ - - -/** Function that (re)generates the dynamic manifest. - * - * @param handle Pointer to an uninitialized dynamic manifest generator handle. - * - * @param features NULL terminated array of LV2_Feature structs which - * represent the features the host supports. The dynamic manifest geenrator may - * refuse to (re)generate the dynamic manifest if required features are not - * found here (however hosts SHOULD NOT use this as a discovery mechanism, - * instead of reading the static manifest file). This array must always exist; - * if a host has no features, it MUST pass a single element array containing - * NULL. - * - * @return 0 on success, otherwise a non-zero error code. The host SHOULD - * evaluate the result of the operation by examining the returned value and MUST - * NOT try to interpret the value of handle. - */ +/** + Generate the dynamic manifest. + + @param handle Pointer to an uninitialized dynamic manifest generator handle. + + @param features NULL terminated array of LV2_Feature structs which represent + the features the host supports. The dynamic manifest generator may refuse to + (re)generate the dynamic manifest if required features are not found here + (however hosts SHOULD NOT use this as a discovery mechanism, instead of + reading the static manifest file). This array must always exist; if a host + has no features, it MUST pass a single element array containing NULL. + + @return 0 on success, otherwise a non-zero error code. The host SHOULD + evaluate the result of the operation by examining the returned value and + MUST NOT try to interpret the value of handle. +*/ int lv2_dyn_manifest_open(LV2_Dyn_Manifest_Handle * handle, const LV2_Feature *const * features); -/** Function that fetches a "list" of subject URIs exposed by the dynamic - * manifest generator. - * - * The dynamic manifest generator has to fill the resource only with the needed - * triples to make the host aware of the "objects" it wants to expose. For - * example, if the plugin library exposes a regular LV2 plugin, it should output - * only a triple like the following: - * - * a lv2:Plugin . - * - * The objects that are elegible for exposure are those that would need to be - * represented by a subject node in a static manifest. - * - * @param handle Dynamic manifest generator handle. - * - * @param fp FILE * identifying the resource the host has to set up for the - * dynamic manifest generator. The host MUST pass a writable, empty resource to - * this function, and the dynamic manifest generator MUST ONLY perform write - * operations on it at the end of the stream (e.g., using only fprintf(), - * fwrite() and similar). - * - * @return 0 on success, otherwise a non-zero error code. - */ +/** + Fetch a "list" of subject URIs described in the dynamic manifest. + + The dynamic manifest generator has to fill the resource only with the needed + triples to make the host aware of the "objects" it wants to expose. For + example, if the plugin library exposes a regular LV2 plugin, it should + output only a triple like the following: + + a lv2:Plugin . + + The objects that are elegible for exposure are those that would need to be + represented by a subject node in a static manifest. + + @param handle Dynamic manifest generator handle. + + @param fp FILE * identifying the resource the host has to set up for the + dynamic manifest generator. The host MUST pass a writable, empty resource to + this function, and the dynamic manifest generator MUST ONLY perform write + operations on it at the end of the stream (e.g., using only fprintf(), + fwrite() and similar). + + @return 0 on success, otherwise a non-zero error code. +*/ int lv2_dyn_manifest_get_subjects(LV2_Dyn_Manifest_Handle handle, FILE * fp); -/** Function that fetches data related to a specific URI. - * - * The dynamic manifest generator has to fill the resource with data related to - * object represented by the given URI. For example, if the library exposes a - * regular LV2 plugin whose URI, as retrieved by the host using - * lv2_dyn_manifest_get_subjects() is http://www.example.com/plugin/uri, it - * should output something like: - * - * a lv2:Plugin ; - * doap:name "My Plugin" ; - * lv2:binary ; - * ... etc... - * - * @param handle Dynamic manifest generator handle. - * - * @param fp FILE * identifying the resource the host has to set up for the - * dynamic manifest generator. The host MUST pass a writable resource to this - * function, and the dynamic manifest generator MUST ONLY perform write - * operations on it at the current position of the stream (e.g. using only - * fprintf(), fwrite() and similar). - * - * @param uri URI to get data about (in the "plain" form, i.e., absolute URI - * without Turtle prefixes). - * - * @return 0 on success, otherwise a non-zero error code. - */ +/** + Function that fetches data related to a specific URI. + + The dynamic manifest generator has to fill the resource with data related to + object represented by the given URI. For example, if the library exposes a + regular LV2 plugin whose URI, as retrieved by the host using + lv2_dyn_manifest_get_subjects() is http://www.example.com/plugin/uri, it + should output something like: + + a lv2:Plugin ; + doap:name "My Plugin" ; + lv2:binary ; + # ... etc... + . + + @param handle Dynamic manifest generator handle. + + @param fp FILE * identifying the resource the host has to set up for the + dynamic manifest generator. The host MUST pass a writable resource to this + function, and the dynamic manifest generator MUST ONLY perform write + operations on it at the current position of the stream (e.g. using only + fprintf(), fwrite() and similar). + + @param uri URI to get data about (in the "plain" form, i.e., absolute URI + without Turtle prefixes). + + @return 0 on success, otherwise a non-zero error code. +*/ int lv2_dyn_manifest_get_data(LV2_Dyn_Manifest_Handle handle, FILE * fp, const char * uri); -/** Function that ends the operations on the dynamic manifest generator. - * - * This function SHOULD be used by the dynamic manifest generator to perform - * cleanup operations, etc. - * - * Once this function is called, referring to handle will cause undefined - * behavior. - * - * @param handle Dynamic manifest generator handle. - */ +/** + Function that ends the operations on the dynamic manifest generator. + + This function SHOULD be used by the dynamic manifest generator to perform + cleanup operations, etc. + + Once this function is called, referring to handle will cause undefined + behavior. + + @param handle Dynamic manifest generator handle. +*/ void lv2_dyn_manifest_close(LV2_Dyn_Manifest_Handle handle); #ifdef __cplusplus @@ -206,4 +140,3 @@ void lv2_dyn_manifest_close(LV2_Dyn_Manifest_Handle handle); #endif #endif /* LV2_DYN_MANIFEST_H_INCLUDED */ - diff --git a/ext/dynmanifest.lv2/dynmanifest.ttl b/ext/dynmanifest.lv2/dynmanifest.ttl index 396eb2f..591cb11 100644 --- a/ext/dynmanifest.lv2/dynmanifest.ttl +++ b/ext/dynmanifest.lv2/dynmanifest.ttl @@ -38,18 +38,72 @@ doap:maintainer [ a foaf:Person ; foaf:name "Stefano D'Angelo" - ] . + ] ; + 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:subClassOf lv2:Resource ; rdfs:label "Dynamic manifest generator" ; rdfs:subClassOf [ - a owl:Restriction ; - owl:onProperty rdf:type ; - owl:hasValue dman:DynManifest ; - rdfs:comment "A DynManifest has rdf:type dman:DynManifest." - ] , [ a owl:Restriction ; owl:onProperty lv2:binary ; owl:minCardinality 1 ; diff --git a/ext/dynmanifest.lv2/manifest.ttl b/ext/dynmanifest.lv2/manifest.ttl index a23e849..6718092 100644 --- a/ext/dynmanifest.lv2/manifest.ttl +++ b/ext/dynmanifest.lv2/manifest.ttl @@ -1,9 +1,9 @@ -@prefix lv2: . +@prefix lv2: . @prefix rdfs: . a lv2:Specification ; lv2:minorVersion 1 ; lv2:microVersion 1 ; - rdfs:seeAlso . - + rdfs:seeAlso , + . -- cgit v1.2.1