A typical plugin available under bridging subdirectory is built as a shared library which is loaded by the mpm library. Please refer to the links on how to build and how to run a sample for information related to building the plugins and running them.
Every plugin must have the implementation of following functions:
Upon receiving a load request by the client, an instance of the requested plugin is loaded. The state a plugin begins with is pluginCreate. Within this state of the plugin lifecycle, a plugin specific context is created and initialized.
pluginCreate is followed by pluginStart. In this state, plugin is made ready to be able to service client requests by making loop control variable true. Any thread to monitor devices, if required during the course of plugin operation is spawned here.
SARR stands for Scan-Add-Remove-Reconnect. The plugin continues to be in this state until a pluginStop request is received by the plugin from the client via mpm library. In this state, plugin is in service mode and accepts and performs client requests. The four basic client requests, better known as SARR operations, which are serviced in this state are:
> pluginScan: This operation takes place upon receiving MPM_SCAN message. The plugin scans for the available devices, generates uri for each one of the found device and triggers a response to the client informing the client about the found device. Internally, it may maintain a uri to device map to keep track of scanned devices. > pluginAdd: This operation usually follows scan. Upon receiving a MPM_ADD message from the client along with the device uri to be added, appropriate number of resources as predefined in the plugin are created in discoverable mode. Metadata is also prepared and is cbor-encoded. Response containing metadata is sent back to the client to be used later for reconnect. Internally, a uri to added_device map may be maintained to track added devices. > pluginRemove: This operation serves client's request to delete the resources associated with a particular device as identified by the uri sent with the remove request. The iotivity resources created during pluginAdd for the device are deleted, entries from the maps if any are cleared and a response is triggered back to the client to indicate the success or failure of servicing the remove request. > pluginReconnect: This is a one-time operation which is usually triggered by the client when the plugin starts. The main idea behind this operation is to connect the devices connected in the last session in case of a crash or reboot. For each reconnect request, the plugin creates appropriate iotivity resource(s) and updates the maps (if required) to track the devices reconnected.
Once a plugin stop request is received, the state of plugin changes from pluginOps to pluginStop. The loop control variable is made false to make the plugin stop servicing requests. All the iotivity resources created are lined up for deletion. The maps maintained(if any) are cleared and any thread spawned during pluginStart is joined for clean-up.
Here, the plugin specific context created during pluginCreate is freed up and the plugin is terminated.