TCE plugins
Basic overview
When peers in a TCE session have loaded a plugin, each peer will host a local instance of that plugin. These instances of the plugin can interact with things like servers and crypto chains, and can communicate with each other through the TCE session by sending and reading plugin transactions, which TCE will attach to ConsensusEvent
s. Plugin transactions are not publicly visible to the application layer.
The application layer can interact with plugins by executing asynchronous functions in the plugin ("plugin commands"), and can receive feedback from plugins through the PluginEvents
fields on finalized messages. If a plugin is implemented correctly, the plugin events attached to each finalized message by that plugin should be consistent between all creators in the session who have loaded that plugin.
Adding plugins to TCE
When initializing the TCE platform and configuring it as described here you will need to set these additional configuration options on the PlatformConfig
.
.EnablePlugin(bool)
All plugin functionality is disabled by default, set this totrue
to enable it..PluginPath(String)
The path to the plugin directory. Defaults to the relative path"./plugins"
. TCE searches the plugin directory recursively for plugins..AddPlugin(String)
Pass the filename of a plugin in the plugin directory to add it to the session. Plugins take the form of dynamic libraries, for example"p_evm.dll"
. The exact filename will vary depending on the platform (for example, the same plugin might be called"libp_evm.so"
on Linux).
Plugin bindings
A plugin's author should supply bindings that make it easy to use. Here's an example of what the bindings for a hypothetical plugin could look like.
For technical details about how plugin bindings integrate with the TCE Platform
, refer to the tce-plugin-common repo.
Last updated