Plugin System/API/Data Storage

Data reuse is very efficient within any single address space, but this efficiency is generally lost when data is to be shared between two or more processes with separate address spaces. There are some solutions to this, such as shared memory segments, but the problem gets worse when cooperating processes may reside on separate machines. The following (loose) command specification describes a low-level requirement that overcomes this problem for plugins, by storing data in an associative store within the viewer. The command names shown are just placeholders:

The following primitive data-storage functions should be available:
 * putKeyData [nameSpace::]aKey aDatum
 * Transferred datum is stored under [nameSpace::]aKey, surviving remote handler termination.


 * getKeyData [nameSpace::]aKey
 * Requests the data stored under [nameSpace::]aKey


 * getKeyType [nameSpace::]aKey
 * Requests the type of data stored under [nameSpace::]aKey


 * deleteKey [nameSpace::]aKey
 * Deletes the data stored under [nameSpace::]aKey, not the key itself


 * listKeys nameSpace
 * Lists all the keys held in the namespace nameSpace.

A key referenced by a plugin without an explicit namespace prefix is equivalent to a key in a namespace of the same name as the plugin. (Plugins define a name for themselves during connection setup.)

Given appropriate command handlers that interpret certain fields as keys, this would allow any one plugin to send data once and then use it multiple times, or multiple plugins to share data between them.

Note that namespaces should be private and transient by default, ie. not accessible by any other plugin, and flushed when their creator plugin disconnects. Shared namspaces require plugin authentication to work effectively in a malicious environment, but a weaker form that relies on plugin self-identification is still very useful during development or in restricted environments, simply to avoid unwanted plugin collisions.

Namespaces may eventually gain other attributes if the need arises. A useful set might include:


 * private -- only the plugin that created the namespace can access it
 * readable -- other plugins can read the namespace
 * writable -- other plugins can read and write to it
 * public -- other plugins can read, write, and delete it
 * persistent -- the namespace and its keys survive disconnection by their owner plugin
 * transient -- the viewer should free all the keys in the namespace on owner disconnection