Summary and Scope

Up to now a rdkservice (aka thunderplugin) was typically coded to be bundled into one single .so file.

While this is mostly fine for rdkservices/plugins used in a "in-process" config - this means loaded within same process as core thunder process (the WPEFramework process), this has important drawbacks for rdkservices/plugins used in "out-of-process/out-of-container" config when it comes to total memory consumption and security exposure of container running core thunder process(the WPEFramework process). examples of important rdkservices running out-of-container are OpenCDMi, WebKitBrowser plugins

This page solves this drawback by splitting the out-of-processs/container rdkservices/thunderplugin .so into .so part for WPEframework/thunder process and Impl.so part for rdkservice/thunderplugin process and describes convention on how to do this.

Problem description 

Before starting with a description of the problem we are trying to solve here, first small paragraph about split between thunder core and thunder plugins into processes & containers & their terminology/names because this can be confusing and it is required to be on same page there before rest of page can be understood.

The Core thunder process is named WPEFramework process.  That process is typically* running in a dedicated container, let's assume for sake of this explanation that name of that container is  WPEFRAMEWORK container.  When a thunder plugin is configured as in-process it is running within that WPEFramework process (and obviously within that same WPEFRAMEWORK container). Typically for robustness (eg cgroup memory limiting) and security design , several of the rdkservices/thunderplugin do need to run in separate containers.  In that case, the thunder plugin is running in a separate process, normally with WPEProcess in its name and has to be configured to run out-of-process/out-of-container. 

(*) whether or not the core thunder process runs in dedicated container can depend on operator. For Liberty Global it required to be in separate container for various reasons, one being the security design, core thunder process exposes api's to 3rd party apps via network (ws) and need to restrict attack surface/thread exposure.