Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

draw.io Diagram
bordertrue
diagramNameThunder_framework
simpleViewerfalse
width
linksauto
tbstyletop
lboxtrue
diagramWidth1242
revision2

Modular architecture

  • The system is build up from several  layers. The functionality is contained in  modules.

Separation of concern

  • A nano/micro service has its own  dedicated task/function and fulfils this.  No managers!

Interface based

  • Interconnection between plugins is  based on interfaces.

Architectural Focus

Agnostic to process boundaries (JSONRPC/COMRPC)

  • For security and stability functionality is realized in contained processes. To communicate to process boundaries we need JSONRPC/COMRPC.

Integral implementation of security features 

  • LXC containerization, including users and groups per processes.

Small footprint, low resource usage

  • Building it, only requires ZLIB.

Uniformity

  • All configuration is stored as JSON and read from 1 location, RESTFull API alignment  JSON field names always lowercase, path names Pascal case.

Features

WebControl

  • WPEFramework can be controlled from a webbrowser client on your PC.

Scoped Traceability (controlled from Web)

  • Fine granularity, trace what you need, Web Browser UI to control it all..

Execution architecture (resource constrained)

  • One thread to communicate all.Thread pools.

Ease of use when building a plugin

  • Object oriented approach for communication (JSON, HTTP, WebSocket, COM/JSON RPC).

No hard-linked dependencies

...

  • There is NO dependency between the plugins. Use subsystems !!!!

...

JSONRPC/COMRPC Process transparency

...

  • 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 .

...

Resources opened up through JSONRPC

...