Logo Search packages:      
Sourcecode: naspro-bridges-bad version File versions  Download package

dyn-manifest.h File Reference


Detailed Description

Revision: 2

== 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 (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 plugin API.

== Accessing data ==

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

  1. Call lv2_dyn_manifest_open();
  2. Create an empty resource identified by a FILE *;
  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, 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);
  5. Call lv2_dyn_manifest_close();
  6. Parse the content of the FILE * resource(s).
  7. 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 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.) in functions from the Dynamic manifest open class (the open-like operation MUST fail). For this purpose, use of a static boolean flag is suggested.

== Threading rules ==

This specification defines threading rule classes, similarly to the LV2 specification.

The functions defined by this API belong to:

The rules that hosts must follow are these:

Extensions to this specification which add new functions MUST declare in which of these classes the functions belong, or define new classes for them; furthermore, classes defined by such extensions MUST only allow calls after a successful call to a function from the Dynamic manifest open class and before the following successful call to a function from the Dynamic manifest close class.

Any simultaneous calls that are not explicitly forbidden by these rules are allowed.

Definition in file dyn-manifest.h.

#include <stdio.h>
#include <lv2.h>

Go to the source code of this file.

Defines

#define LV2_DYN_MANIFEST_URI   "http://lv2plug.in/ns/ext/dyn-manifest"

Typedefs

typedef void * LV2_Dyn_Manifest_Handle

Functions

void lv2_dyn_manifest_close (LV2_Dyn_Manifest_Handle handle)
int lv2_dyn_manifest_get_data (LV2_Dyn_Manifest_Handle handle, FILE *fp, const char *uri)
int lv2_dyn_manifest_get_subjects (LV2_Dyn_Manifest_Handle handle, FILE *fp)
int lv2_dyn_manifest_open (LV2_Dyn_Manifest_Handle *handle, const LV2_Feature *const *features)


Generated by  Doxygen 1.6.0   Back to index