From cb8967dd41ccd8fe25a8eb19d66f53c75daf0e8d Mon Sep 17 00:00:00 2001
From: David Robillard <d@drobilla.net>
Date: Wed, 9 Nov 2011 20:34:03 +0000
Subject: Update documentation.
---
ext/state.lv2/state.h | 13 +++++----
ext/state.lv2/state.ttl | 75 +++++++++++++++++++++++++------------------------
2 files changed, 45 insertions(+), 43 deletions(-)
diff --git a/ext/state.lv2/state.h b/ext/state.lv2/state.h
index 82105e5..6ada0e1 100644
--- a/ext/state.lv2/state.h
+++ b/ext/state.lv2/state.h
@@ -83,7 +83,7 @@ typedef enum {
/**
A host-provided function to store a property.
- @param callback_data Must be the callback_data passed to LV2_State_Interface.save().
+ @param handle Must be the handle passed to LV2_State_Interface.save().
@param key The key (predicate) to store @c value under (URI mapped integer).
@param value Pointer to the value (object) to be stored.
@param size The size of the data at @c value in bytes.
@@ -117,7 +117,7 @@ typedef int (*LV2_State_Store_Function)(LV2_State_Handle* handle,
/**
A host-provided function to retrieve a property.
- @param callback_data Must be the callback_data passed to
+ @param handle Must be the handle passed to
LV2_State_Interface.restore().
@param key The key (predicate) of the property to retrieve (URI).
@param size (Output) If non-NULL, set to the size of the restored value.
@@ -132,12 +132,13 @@ typedef int (*LV2_State_Store_Function)(LV2_State_Handle* handle,
plugin within LV2_State_Interface.restore() to retrieve any properties it
requires to restore its state.
- The returned value MUST remain valid until LV2_State_Interface.restore() returns.
+ The returned value MUST remain valid until LV2_State_Interface.restore()
+ returns.
The plugin MUST NOT attempt to use this function, or any value returned from
- it, outside of the LV2_State_Interface.restore() context. Returned values MAY be
- copied for later use if necessary, assuming the plugin knows how to do so
- correctly (e.g. the value is POD, or the plugin understands the type).
+ it, outside of the LV2_State_Interface.restore() context. Returned values
+ MAY be copied for later use if necessary, assuming the plugin knows how to
+ do so correctly (e.g. the value is POD, or the plugin understands the type).
*/
typedef const void* (*LV2_State_Retrieve_Function)(LV2_State_Handle handle,
uint32_t key,
diff --git a/ext/state.lv2/state.ttl b/ext/state.lv2/state.ttl
index 328dcc9..6456520 100644
--- a/ext/state.lv2/state.ttl
+++ b/ext/state.lv2/state.ttl
@@ -43,37 +43,35 @@
] ;
lv2:documentation """
<p>This extension provides a mechanism for plugins to save and restore state
-across instances, allowing hosts to save configuration/state/data with a
-project or fully clone (i.e. make a deep copy of) a plugin instance.</p>
-
-<p>This extension allows plugins to save private state data, i.e. data that is
-not contained in input ports. The motivating ideal is for the state of a
-plugin instance to be <em>entirely</em> described by port values (as with all
-LV2 plugins) and a key/value dictionary as defined by this extension. This
-mechanism is simple, yet sufficiently powerful to describe very advanced and
-complex state.</p>
+across instances, allowing hosts to save, restore, clone, or take a snapshot of
+a plugin instance's state at any point in time. The intention is for a plugin
+instance's state to be <em>completely</em> described by port values (as with all
+LV2 plugins) and a simple dictionary.</p>
<p>The <q>state</q> described by this extension is conceptually a single
-key/value dictionary. Keys are URIs, and values are type-tagged blobs of any
-type. The plugin provides a save and restore method for saving and restoring
-state. To initiate a save or restore, the host calls these methods, passing a
-callback to be used for handling a single key/value pair. The host is free to
-implement saving and restoring in any way; the actual mechanism is completely
-abstract from the plugin's perspective.</p>
-
-<p>Because the state is a simple dictionary, hosts and plugins can work with
-state easily from many languages and protocols. Additionally, this format is
-simple and terse to serialise in many formats (e.g. any RDF syntax, JSON, XML,
-key/value databases such as BDB, etc.). In particular, state can be elegantly
-described in a plugin's Turtle description, which is useful for e.g. presets or
-default state.</p>
+key/value dictionary, where keys are URIDs and values are type-tagged blobs of
+any type. The plugin provides an LV2_State_Interface for working with this
+state. To save or restore, the host calls LV2_State_Interface::save() or
+LV2_State_Interface::restore(), passing a callback to be used for handling a
+single key/value pair. The host is free to implement saving and restoring in
+any way; the actual mechanism is completely abstract from the plugin's
+perspective.</p>
+
+<p>Because state is a simple dictionary, hosts and plugins can work with it
+easily from many languages and protocols. Keys are URIDs for performance
+reasons as well as RDF compatibility, which makes it simple to serialise state
+in many formats (e.g. any RDF syntax, JSON, XML, key/value databases such as
+BDB, etc.). In particular, state can be elegantly described in a plugin's
+Turtle description, which is useful for e.g. presets or default state.
+Specific keys may be described in Turtle on the fly or in extensions,
+allowing plugins to use common well-defined keys.</p>
<p>This extension defines a conceptual model of state and a mechanism for
-saving and restoring it, but no interface for manipulating that state
-dynamically. It is intended that a generic way to modify this state (e.g.
-with messages sent via ports) is the preferred way to achieve more advanced
-plugin control than control ports provide, but the details of this mechanism
-should be addressed by a separate extension.</p>
+saving and restoring it, but no interface for manipulating it dynamically.
+While no such mechanism is defined here, dynamic control of plugins SHOULD be
+achieved by generic manipulations of the same conceptual state dictionary used
+by this extension (e.g. <code>plugin->set(key, value)</code>). Accordingly,
+plugins SHOULD use meaningful and well-defined keys wherever possible.</p>
<p>In pseudo code, a typical use case in a plugin is:</p>
<pre class="c-code">
@@ -89,15 +87,17 @@ LV2_Handle my_instantiate(...)
return plugin;
}
-void my_save(LV2_Handle instance,
- LV2_State_Store_Function store,
- void* callback_data,
- uint32_t flags)
+void my_save(LV2_Handle instance,
+ LV2_State_Store_Function store,
+ void* handle,
+ uint32_t flags,
+ const LV2_Feature *const * features)
+
{
MyPlugin* plugin = (MyPlugin*)instance;
const char* greeting = plugin->state.greeting;
- store(callback_data,
+ store(handle,
plugin->uris.eg_greeting,
greeting,
strlen(greeting) + 1,
@@ -107,15 +107,16 @@ void my_save(LV2_Handle instance,
void my_restore(LV2_Handle instance,
LV2_State_Retrieve_Function retrieve,
- void* callback_data,
- uint32_t flags)
+ void* handle,
+ uint32_t flags,
+ const LV2_Feature *const * features)
{
MyPlugin* plugin = (MyPlugin*)instance;
size_t size;
uint32_t type;
uint32_t flags;
- const char* greeting = retrieve(callback_data,
+ const char* greeting = retrieve(handle,
plugin->uris.eg_greeting,
&size,
&type,
@@ -140,7 +141,7 @@ const void* my_extension_data(const char* uri)
<p>Similarly, a typical use case in a host is:</p>
<pre class="c-code">
-int store_callback(void* callback_data,
+int store_callback(void* handle,
uint32_t key,
const void* value,
size_t size,
@@ -152,7 +153,7 @@ int store_callback(void* callback_data,
If this was for disk or network storage/transmission,
LV2_STATE_IS_PORTABLE would have to be checked as well.
*/
- Map* state_map = (Map*)callback_data;
+ Map* state_map = (Map*)handle;
state_map->insert(key, Value(copy(value), size, type, pod));
return 0;
} else {
--
cgit v1.2.1