<<Work in progress>>

RDK Services

RDK Services or Thunder Plugins are available in:. 

           repo url: https://github.com/rdkcentral/rdkservices.git

  bitbake recipe: https://code.rdkcentral.com/r/plugins/gitiles/components/generic/rdk-oe/meta-rdk-video/+/refs/heads/rdk-next/recipes-extended/rdkservices/rdkservices_git.bb

Typical structure of project tree of thunder plugin

Steps to add new Open Source RDK Service

RDKServices github repo will get checked out under /tmp/work folder and changes can be made there. 

tmp/work/mips32el-rdk-linux/rdkservices/3.0+gitAUTOINC+fa49ddedd1-r1/git

Here is the description step by step to add new plugin with the name SimpleService based on the file structure of DisplaySettings.  Display settings requires IARM and DeviceSettings libraries.  Other services may not have these dependencies, depending upon their complexity.

  1. copy the folder  tmp/work/mips32el-rdk-linux/rdkservices/3.0+gitAUTOINC+fa49ddedd1-r1/git/DisplaySettings to SimpleService with full content;
  2. in folder tmp/work/mips32el-rdk-linux/rdkservices/3.0+gitAUTOINC+fa49ddedd1-r1/git/SimpleService rename all files DisplaySettings to SimpleService, keeping the current extensions
  3. Rename all cases of DisplaySettings to SimpleService in all files under SimpleService;

  4. Refactor each of the plugin methods.
    1. getQuirks - this should be done for any plugin that defines it.  Quirks are the mechanism to describe any low level bugs or changes that may have been fixed within a specific API version.
    2. API methods
    3. API events
    4. Do not refactor any methods not part of the API, with exception of getQuirks above.  Note that the Javascript related methods were intended for use with Javascript clients through QtWebkit and do not need to be included in the Thunder service.  getJavaScriptObject and <servicename>JavaScriptObject are examples of these.
  5. Legacy services are using Qt library, thunder plugin should not use it. So the std::vector or std::list can be used instead of QList, std::thread instead of QThread, WPEFramework::Core::TimerType instead of QTimer.
  6. Now everything is available to build the new plugin:
    • bitbake rdkservices
  7. Copy files on stb: etc/WPEFramework/plugins/SimpleService.json and usr/lib/wpeframework/plugins/libWPEFrameworkSimpleService.so
  8. Restart thunder and test new plugin:
  9. Result for these steps should be:
     {"jsonrpc":"2.0","id":3,"result":{"quirks":["XRE-7389","DELIA-16415","RDK-16024","DELIA-18552"],"success":true}}

     

Now SimpleService can be refactored to exclude all unused methods, events and additional code, which are no longer required. 


Adding new versions for RDK Services

All RDK Services will start with version 1. If there are client-facing changes (adding or removing methods; adding, removing or changing parameters in methods; changing event names or payloads) then the version number of the service needs to be incremented. Here are the details on how to increment the version.

Versions are maintained in different JSONRPC handlers. We need to specify the list of versions as an array to each of these handlers.   

Assuming we are adding a new API setFoo() to version 2 for DisplaySettings plugin. We need to create a new JSONRPC handler for this version. This basically takes an array of versions that are supported by this handler. 

           
DisplaySettings.cpp

DisplaySettings::DisplaySettings()
: AbstractPlugin()
{...// Create JSONRPC handler for version 2. The last parameter makes sure that all handlers are copied from the base version to this new one...
Core::JSONRPC::Handler& Version_2 = JSONRPC::CreateHandler({ 2 }, *this);
 
// Register the new method in version 2 to this handler.
Version_2.Register<Core::JSON::String>(_T("setFoo"), &DisplaySettings::setFoo, this);
}
 
//version 2 APIs
void DisplaySettings::setFoo(Core::JSON::String)
{
}

  • No labels

6 Comments

  1. Deepthi Suseelan In looking at the rdkservices webinar. There is discussion of COM/rpc, JSON/rpc and C++ interfaces that can be used to communicate to rdkservices.  create json rpc interfaces to rdkservices.   

    -I have looked high and low and there does not seem to be any C++ interface that abstracts the JSon RPC communication to rdkservices as described in the webinar.  Please let me know if this is true.   

    Also, there is no COM/rpc except under build-vip78x2w/tmp/work/cortexa15t2hf-neon-rdk-linux-gnueabi/thunder-services/git-r1/git/examples  where it seems metrological had started an example for COM/rpc. So I assume not many people have gone in this direction.  Please let me know if you feel this is correct.  The only example code I could find is in 

    It seems that we need to build a C++ JSon rpc interface is the way to go for all rdkservices interface.   just an FYI here at CommScope we are working on apps for RDK both embedded and inside a dac so that is why we need these interfaces.  The only examples I could find are listed below. Is there any more sample code to communicate to rdkservices that you could provide.  Thank you!!!

    https://github.com/rdkcentral/rdkservices/tree/sprint/2102/RemoteActionMapping/test

    https://github.com/rdkcentral/rdkservices/tree/sprint/2102/ControlService/test

    https://github.com/rdkcentral/rdkservices/tree/sprint/2102/StateObserver/test

    https://github.com/rdkcentral/rdkservices/tree/sprint/2102/SystemServices/TestClient

    https://github.com/rdkcentral/rdkservices/tree/sprint/2102/TextToSpeech/test

    https://github.com/rdkcentral/rdkservices/tree/sprint/2102/WifiManager/test

  2. @Deepthi Suseelan in looking at the examples above - they are based on having the wpeframework namespace which means all the Thunder.js type abstraction is inside of the framework. Seems that the Metrological Thunder.js is most beneficial for application developers.  What about C++ applications, is there any help to abstract the json rpc / websockets code development effort?   I appreciate your help!  

  3. Z-Chris Del Sordo

    I am checking this with Comcast component owner. Will post the reply here.

  4. Deepthi,

    Thank you for any guidance.  I was not completely clear on my need however.  I have determined that the above sample code is specifically designed for test.  There are two types of applications that CommScope  needs to develop interfaces to rdk services.  We have a DAC based application that we are developing to show to Liberty Global that requires communication to rdkservices to get the DisplaySettings and serial numbers and key strokes etc.  This application currently is working as an CommScope developed embedded thunder nanoservice (ie rdkservice)  and we would like to abstract the low level platform calls being done in the embedded version to use rdkservices interface as a first step before moving it to RDK DAC.

    As I have mentioned, the COM/rpc interface is an interface that Metrological proposed which can be used.  I believe that this is not a useable option. 

    DAC application developers do not have access to the wpeframework and it really good environment to abstract the details of websockets based json/rpc.  Whereas if you are a JS application developer - you get this for free by importing ThunderJS.  Is there an alternative approach or do I just need to develop  a websockets based json/rpc layer from scratch.

    Chris  

  5. Deepthi,

    Anyone that can help with how to implement JSON/rpc in C++ to communicate to rdkservices.  I have little to go on with the documentation that currently exists.

    Chris

    1. Z-Chris Del Sordo 

      We have taken this point with Comcast architecture team and a meeting is scheduled to discuss this in detail.