<< Work in progress >>

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

...

Plugin Development in wpeframework-plugins

...

In wpeframework-plugins

...

workspace :

(cloned from https://github.com/WebPlatformForEmbedded/ThunderNanoServices/)

Create PluginName folderfolder 

Inside PluginName directory:

12. Create a Makefile “CmakeLists.txt” to compile the Plug-in code and to generate the shared library (“.so”)

This will handle all the dependencies as well

32. Module.h: This header file includes the support for JSON request, response, logging etc.,

43. Module.cpp: This file is used to declare the module name for the Plug-in

54. <PluginName>Plugin.json:

This file contains the plugin's information like schema, information and interface json file etc.,(defined earlier)

            Ex:-

{
  "$schema": "plugin.schema.json",
  "info": {
    "title": "Plugin Name Plugin",
    "callsign": "PluginName",
    "locator": "libWPEFrameworkPluginName.so",
    "status": "production",
    "description": "The PluginName plugin allows retrieving of various plugin-related information.",
    "version": "1.0"
  },
  "interface": {
    "$ref": "{interfacedir}/PluginName.json#"
  }
}

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

Ex:- set (autostart true)

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

We can set some other parameters based on our need

76. <PluginName>.h

Declare the plugin class in this which should contains all the structures, variables and methods which are needed for plugin implementation. The interface header auto-generated earlier will be used here,

...

virtual Core::ProxyType<Web::Response> Process(const Web::Request& request) override;

 8 7. <PluginName>.cpp: This class does contains all the definitions for the methods declared in the Plugin.h and those definitions should be defined inside the below namespace. 

...

namespace WPEFramework {
	namespace Plugin {  
		SERVICE_REGISTRATION(Plugin, 1, 0);
		//All the methods declared in Plugin.h should be defined here
	}
}

 9 8.  <PluginName>JsonRpc.cpp: This class is used to register the methods with JSON RPC interface as below

...

uint32_t Plugin::get_method(ClassName& response) const
{
	//body of the method
}

uint32_t Plugin::set_method(ClassName& response) const
{
	//body of the method
}       

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/ 

or in workspace of RDK4.0 Beta build:

(rdkv_4.0_beta/build-raspberrypi-rdk-hybrid-thunder/tmp/work/cortexa7t2hf-neon-vfpv4-rdk-linux-gnueabi/wpeframework-plugins/3.0+gitrAUTOINC+886f9025b3-r1/git/)

for further clarifications

Compilation and Install

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

bitbake wpeframework-plugins

will generate <PluginName>.json and libWPEFrameworkPlugin.so

Copy the plugin library (libWPEFrameworkPlugin.so) to “/usr/lib/wpeframework/plugins” 

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

If the plug-in got activated, it will be listed in the WebUI and using Controller plug-in we can control (activate / deactivate) the newly added plugin

Validation

REST APIs based curl command:

Request:

$ curl --request GET http://127.0.0.1:9998/Service/<pluginName>/<function>

eg: $ curl --request GET http://127.0.0.1:9998/Service/Picture/Brightness

Response:

{"brightness":100}

JSON RPC APIs based curl command:

Request:

$ curl --data-binary '{"jsonrpc": "2.0", "id": 3, "method": "Picture.1.brightness"}' http://127.0.0.1:9998/jsonrpc

Response:

{"jsonrpc":"2.0","id":3,"result":{"brightness":100},"success"}