From cb8967dd41ccd8fe25a8eb19d66f53c75daf0e8d Mon Sep 17 00:00:00 2001 From: David Robillard 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 """

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.

- -

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 entirely 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.

+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 completely described by port values (as with all +LV2 plugins) and a simple dictionary.

The state 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.

- -

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.

+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.

+ +

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.

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.

+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. plugin->set(key, value)). Accordingly, +plugins SHOULD use meaningful and well-defined keys wherever possible.

In pseudo code, a typical use case in a plugin is:

@@ -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)
 
 
Similarly, a typical use case in a host is:

 
-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