From 725d4a404b838da6b67d9da66228a1125bddef57 Mon Sep 17 00:00:00 2001 From: David Robillard Date: Sun, 20 Nov 2011 23:08:57 +0000 Subject: Lay out repository structure to match include and URI structure. Treat lv2core like all the other specifications in gendoc.py. --- ns/ext/dynmanifest/dynmanifest.ttl | 122 +++++++++++++++++++++++++++++++++++++ 1 file changed, 122 insertions(+) create mode 100644 ns/ext/dynmanifest/dynmanifest.ttl (limited to 'ns/ext/dynmanifest/dynmanifest.ttl') diff --git a/ns/ext/dynmanifest/dynmanifest.ttl b/ns/ext/dynmanifest/dynmanifest.ttl new file mode 100644 index 0000000..591cb11 --- /dev/null +++ b/ns/ext/dynmanifest/dynmanifest.ttl @@ -0,0 +1,122 @@ +# LV2 Dynamic Manifest Extension +# 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 +# copyright notice and this permission notice appear in all copies. +# +# THIS SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES +# WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF +# MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR +# ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES +# WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN +# ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF +# OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. + +@prefix dman: . +@prefix doap: . +@prefix foaf: . +@prefix lv2: . +@prefix owl: . +@prefix rdf: . +@prefix rdfs: . +@prefix xsd: . + + + a doap:Project , + lv2:Specification ; + doap:license ; + doap:name "LV2 Dynamic Manifest" ; + doap:homepage ; + doap:created "2009-06-13" ; + doap:shortdesc "An LV2-based specification for dynamic data generation." ; + doap:programming-language "C" ; + doap:release [ + doap:revision "1.1" ; + doap:created "2011-11-17" + ] ; + 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 lv2:binary ; + owl:minCardinality 1 ; + rdfs:comment """A DynManifest has at least 1 lv2:binary. +The binary must be a library with at least the functions described in +lv2_dyn_manifest.h implemented. +""" + ] ; + rdfs:comment """ +The class which represents a dynamic manifest generator. + +There MUST NOT be any instances of :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