ydk cpp core for multi language bindings support

YDK multi-language binding proposal

Issue to track this proposal is here.

• Background
• Possible solutions
  • Use ncclient
  • Write transport providers in each language
  • Implement core in C++ and have other languages wrap around it
• Use case for YDK app based on language bindings
• Use case for C++ app talking directly to YDK path interface
• YDK C++ core details

Background

The above diagram is the current architecture of YDK-Py. Currently, YDK only supports python bindings for modeling data. For establishing sessions with the device and for transporting the encoded payload, YDK relies on ncclient, a python Netconf client. However, there is a need to support additional language bindings, like C++ and Ruby. However, we might not want to create new Netconf clients in different languages, like Ruby and C++. Similarly, if we were to support other protocols like gRPC in the future, we might not want to create gRPC clients in Ruby, C++ etc. To avoid this duplication and for YDK to be a high performance framework, which can support multiple language bindings, we consider a few possible solutions below.

Possible solutions

Use ncclient

Continue to use ncclient for the transport and session management and YDK-Py provider for encoding/decoding. This means that all the new language bindings like Ruby, C++ etc would have to start interfacing with the python core.

• Pro: YDK-Py already has support for encoding/decoding and has integrated with ncclient for transport and session management
• Con: Having multiple languages interface with a python core will slow things down and might not give us the high performance which is desired for YDK

Write transport providers in each language

Create support for encoding/decoding and protocols like Netconf (and potentially gRPC) in different languages, like Ruby and C++

• Pro: This solution will likely lead to a higher performance than solution 1 above.
• Con: Writing code for encoding/decoding and protocol support in multiple languages will result in duplicated effort and inconsistencies between various language implementations

Implement core in C++ and have other languages wrap around it

Replace ncclient with a C++ Netconf client and replace the encoding/decoding mechanism of YDK-Py provider with a C++ interface which does not rely on language bindings for encoding/decoding. Instead, a new path-based interface is proposed. This new mechanism is referred to as the YDK C++ core. This path-based interface is a generic framework to accept modeled data as input in the form of paths. To illustrate, a path would look something like a CLI command: “configure interface ‘test’”. Further, if we were to add support for new language bindings like C++, Ruby etc, the only work which would be needed to be done is to write translators, which can translate between the language bindings and the path to the data which is being referred to by each binding. Each implementation of YDK language bindings in new languages will wrap around the C++ core. This means that even the existing YDK-Py will eventually have to wrap around this proposed C++ core. Alternatively, if users want to directly interface with the C++ core path-based interface, they can do so by writing C++ apps which interface with the C++ core directly.

• Pro: A path-based C++ core for YDK will provide high performance and will help in avoiding duplicate work in writing support for encoding/decoding and transport in new languages.
• Con: C/C++ libraries are ‘less’ OS-independent than, say, Python. So, extra care has to be taken to ensure support across all major operating systems, like Ubuntu, CentOS, Red Hat, Windows, OS X etc. YDK C++ core use case flow

Use case for YDK app based on language bindings

Use case for C++ app talking directly to YDK path interface

YDK C++ core details