Thunder is a Modular architecture with plug and play design where it has a flexibility to enable or disable any feature just as a plugin.
Key Components available in the THUNDER Framework -
WPE WebKit - powerful low-resource embedded WebKit engine with Wayland support
WPE Backend - Abstraction layer for WPE WebKit with support for MESA based gfx or Wayland/EGL gfx
Thunder - plugin based framework for embedding C/C++ components and bridging the "web" world.
RDK Services - RDK Services are set of services used to access device specific functionality.RDK Services are available for launching browser and native applications.It is built on WPE Framework (aka Thunder).
Thunder is a small framework built for embedded devices. It consists out of the following main components -
Framework Core
Framework Plugins
Framework UI
Thunder and RDK Services are key components for micro services to bring into any Box. Thunder offers an event driven interface framework for subsystem availability signaling to the plugins. This framework is utilized to realize concurrent startup scenario using a conditional evaluation only in case a condition changes. This allows for startup without requiring sleeps, or resource consuming polling mechanisms.
For each micro service, we need to implement one plugin as part of RDK Services, and Nano or microservices should configured as part of any of these subsystems.
Designed for Apps:
Pre-integrated premium apps
Pre-integrated app store
Voice enabled
Lightningtm App Dev Language
WPEFramework goal and Overview
Javascript enabler
Goal is to enable/bridge embedded low level C/C++ technology to the Javascript world and it is done by using Javascript enabler.
Application framework is built on Hardware abstraction Layer, on top of abstraction layer there is a WPE Framework. WPE framework itself dispatched internally that actually starts micro and nano services. Micro and Nano services are exposed to certain interfaces so at the end the system can locked down and executing.
From Apps, there are external input interface that can send in JSONRPC messages, JSONRPC messages through dispatcher will be routed to proper micro/nano services.
Most important part of framework is to make sure we can run processes & separate process, we can run nano/micro services out of process. So, we need to communicate to nano/micro services throughout API's.
These API's are actually incremented in 2 ways.
JSONRPC : Mainly targeted towards Javascript. Javascript talks to JSONRPC , Communication Layer goes into framework then it transit to C and C++ world, then from C and C++ world we can far communicate back to Javascript using JSONRPC .
COMRPC : Internally when we want to communicate with different nano/micro services running in different process we can use COMRPC Process.
Marshalling code,Proxy/Stubs are generated from the C header file!!
Interfaces
C header files with a struct definition and pure abstract methods
It is based on interfaces and its regular struct in header file that is to contract to actually closed down between two plugins or two instances of C&C++.
This struct and interface is to find how we communicate with other plugin or other nano/micro services.
If we define structs there is an application that actually creates marshalling code.
COMRPC
QueryInterface/AddRef/Release
Under struct, there is a layer coming from WPEframework that is called "COMRPC"
COMRPC will make sure Pluming URT isn't there so the queryInterface/AddRef/Release will make sure we can do navigation over the interfaces that our lifetime on the interfaces.
Communication Layers
Domain Sockets
TCP Socket
COMRPC migration is part of WPEFramework. If we have COMRPC 'C' migration, the communication layer below are main sockets for TCP Server. It means we could communicate with any interface to other host.
If a command comes in on settop box ,it will actually be turn into message for eg in above figure ,the Webkit browser will send this message through pipeline to framework. Three pipelines coming out of the settop box, different pipelines for different kind of messages.
Received message will be deserialized that is getting back to original message and do get cpu usage. After which, we will look at the message where it has to sent to, that message will be packed with where it will send to and it is forward on to threadpool.
The threadpool are actually multiple threads maintained by multiple persons. Person pickups the job and secure it ,As in diagram the person is evaluating CPU Usage using machine, CPU Usage value is noted down on the message(eg: CPU usage is 50% in above figure) and send back to from where we initially got the message.
Here messages are handled by thread switch. One is communication thread and the other is thread that handled our request. This way the amount of threads used in the system will not increase when multiple connections are created, the more connections you create it will not lead to multiple threadings .
This gives us information regarding once system is ready ,what kind of micro/nano services are all available. Difference between micro and nano is that micro service actually requires graphics -graphical resources or player resources.