<< Work in progress. Contents are under review >>

Most of the up-to-data examples with the new JSONRPC can be found here : https://github.com/WebPlatformForEmbeddedrdkcentral/ThunderNanoServices/tree/master/examples

This directory contains two Example plugins, called : JSONRPCPlugin and OutOfProcessPlugin.

...

For using the plugins, the documentation (API documentation ) is pretty well documented. This is due to the fact that the documentation is automatically generated from the interface specification. The API specifications for each plugin can be found here:
https://github.com/WebPlatformForEmbeddedrdkcentral/ThunderNanoServices/blob/master/README.md

Plugins can be developed in a large variety, in process, out-of-process, out-of host, and each plugin can exploit a large scale over communication protocols, JSONRPC/COMRPC, MessagePackRPC.

In In-process, we can share the worker pool from the WPEFramework thread pool (it will be used a process which is light weight and does not require its own process space : lot of plugins are in-process (Device Info, RemoteControl, FirmwareControl, TraceControl etc)

Out-of-process is used to run a plugin which is required to handle in a separate process context (if by any action it can affect WPEFramework process, has to be run as out of process), for example BrowserPlugin (cobalt, webkit, spark, Netflix).
It will provide its own thread pool, then also it can communicate with the WPEFramework using COMRPC

OUT-of Host can be run outside the device and connect with the WPEFramework externally. COMRPC is used to communicate between process and it should be used if there is large data. Currently there is no existing plugin, only example plugin: https://github.com/WebPlatformForEmbedded/ThunderNanoServices/tree/master/examples/RemoteHostExample

COMRPC is used to communicate between the plugins (out of process) or to communicate for larger data
https://github.com/WebPlatformForEmbedded/ThunderNanoServices/tree/master/examples/COMRPCClient

JSONRPC is used to fetch/update info to or from plugins externally (most of the plugins provide this in interface, similar to ReST API)
also it can be used from applications : https://github.com/WebPlatformForEmbedded/ThunderNanoServices/tree/master/examples/JSONRPCClient
It will be used only for small data

Message pack also, similar to JSONRPC, we can have example at https://github.com/WebPlatformForEmbedded/ThunderNanoServices/tree/master/examples/JSONRPCClient plugin. But this feature is not exposed outside through the WPEFramework Process. It can implemented by using another application as like https://github.com/WebPlatformForEmbedded/ThunderNanoServices/blob/master/examples/JSONRPCPlugin/JSONRPCPlugin.h#L149

Steps involved in implementing new Thunder Plug-In

...

5.  <PluginName>.config: This file is used to set configurations of the Plug-in 

Ex:- set (autostart true)

Used to make the Plug-in to start automatically along with wpeframework daemon

...

9.  <PluginName>HAL.cpp: Used to communicate to driver layer in order to get some information or to set some properties.

Reference

Please refer to any existing plugins in https://github.com/WebPlatformForEmbedded/ThunderNanoServices/ 

...

Enable the plugin in the main CMakeLists.txt of wpeframework-plugins

bitbake wpeframework-plugins

will generate <PluginName>.json and libWPEFrameworkPlugin.so

...

Copy the Plugin.json file to “/etc/WPEFramework/plugins” so that the controller plugin identify it and list it in the WebUI (controller UI ) 

Restart the service

systemctl restart wpeframework

Using the command “$ journalctl – u wpeframework | grep <plug-in name>” we can identify, if the newly added plug-in got activated or not

...