A plugin is a connectivity module. It is a shared library (.so) file which can be dynamically loaded by the mpm_sample_client executable. The mpm_sample_client loads the plugins by creating a child process for each plugin.
1. A new plugin source code must be placed under the directory <iotivity>/bridging/plugins with an appropriate directory name.
e.g.: lifx_plugin, hue_plugin, etc.
2. In the above directory path, refer to lifx_plugin/SConscript to write SConscript for the new plugin.
3. Also, an entry in the <iotivity>/bridging/SConscript is required for building the new plugin.
e.g.: SConscript(os.path.join('plugins', 'new_plugin', 'SConscript'))
4. Every plugin must link iotivity libraries like liboctbstack, libocsrm etc, and a common library 'libmpmcommon'.
Note: If plugin needs to access the cloud using curl request, then it should link libcurl.
5. Every plugin must include the following header files,
> pluginServer.h > ConcurrentIotivityUtils.h > messageHandler.h
Note: For curl related operations, curlClient.h should be included.
A plugin should be capable of communicating to mpm_sample_client over pipe. It should be able to communicate to the underlying respective stack of that connectivity type and also to the iotivity stack. These communication paths should be initialized while creating a plugin.
Following operations should be supported by the plugin:
SCAN/ADD/REMOVE/RECONNECT takes the path from mpm_sample_client to plugin over pipe. READ and WRITE does not use the mpm_sample_client to route, instead these will be functioned over the iotivity path. These requests are posted over iotivity stack from simpleclient (an iotivity client) and the iotivity server (plugin is the server) responds to these requests over iotivity stack.
NOTE: User can refer to the available plugins for the functionalities of the above operations. However, user always have the flexibility to modify these functionalities as per the requirement.
With respect to plugin, it is the underlying connectivity stack which does DISCOVER and CONNECT when the respective message is received at the plugin, i.e. the message handler at the plugin will receive SCAN and ADD, however the device discovery and ADD to network are unique to the connectivity infrastructure.
The iotivity resources have to be created for each device attribute. e.g.: the hue bulb supports chroma, color, saturation and switch attributes. The resource creation can be done either at the SCAN phase or at the ADD based on the stack’s connecting style (with explicit connect message or joins at the SCAN time itself). Every iotivity resource has to be created with a URI (in the form: /<plugin_name>/<device_id>/<attributename>) and also with an iotivity resource type (e.g.: oic.r.switch for the switch attribute). All the resources are required to be registered with an entity handler which processes the READ/WRITE requests from the simpleclient. This handler talks to the device over the connectivity stack and posts the response back to the simpleclient over the iotivity stack.