This guide helps you set up and debug plugins under development for the Nx Witness Server.

To develop a plugin, download and unpack the Nx Software Development Kit (SDK) archive, which is available with each VMS release. Read the readme.md file in the SDK root folder to learn what plugins are and how to build the included plugin samples.

This guide assumes that you can build and run a plugin and are ready to start developing your own. To start, copy a sample folder of your choice from the samples directory, paste it into the same directory under a new name, and modify it.

This guide covers the infrastructure of plugin development, including code recommendations and debugging techniques. It does not cover VMS domain-specific SDK features.

To learn more about the features that plugins can use or provide:

• Refer to the Doxygen documentation in the SDK at docs/html/index.html.

• Study the provided plugin samples.

Understand the SDK structure

This guide focuses on the Metadata SDK (referred to throughout this guide as the SDK). 
We currently offer three distinct SDKs:

• Video Source SDK

• Storage SDK

• Metadata SDK

Each SDK helps you develop its respective plugin type. For details, see the readme.md in each SDK folder. The SDKs use a reference-counted object model similar to Component Object Model (COM) technology, meaning they share several identical C++ files.

The Metadata SDK is the newest of the three and contains the most recent reference-counting implementation. Future updates will merge all three SDKs, rebasing the domain-specific parts of the Video Source and Storage SDKs onto the Metadata SDK infrastructure.

The SDK package consists of text files, HTML pages, and C++ source code structured as follows:

• src/nx/sdk/ — The SDK Core, which defines the API between the Nx Witness Server and your plugin, along with its helper code. The nx/ and sdk/ subfolders reflect the C++ namespaces.

  • i_*.h — Headers defining the Core interfaces. These interfaces support the plugin infrastructure and are not domain-specific.

  • *.h (without the i_ prefix) — Headers for basic Core features, such as interface classes (header-only classes with pure virtual functions and reference-counted lifecycles) and smart pointers.

  • helpers/ — Optional helper classes and functions to simplify plugin development. Most helpers provide default, extensible implementations of the Core interfaces. To customize them, inherit from a helper class and override the necessary functions.

  • analytics/ — Domain-specific code for creating Analytics Plugins that analyze video and send metadata to the Nx Witness Server. This folder includes interfaces and optional helper code with default implementations.

• nx_kit/ — A standalone helper library. Using nx_kit is optional, but the provided samples and this guide rely on it heavily.

• samples/ — Sample plugins, where each subfolder represents a separate plugin project.

• unit_tests/ — Unit tests for the SDK Core and helpers in the src folder.

• docs/ — HTML API documentation generated by Doxygen for all C++ source code and samples.

• build_samples* — Platform-specific build scripts (for example, .sh for Linux and .bat for Windows).

• readme.md — The main documentation file for the SDK.

The nx_kit helper library

Because the C++ standard library lacks built-in support for features like JSON parsing, .ini file reading, debug/release assertions, and structured logging, the SDK includes the nx_kit library to fill these gaps.

For implementation details, see nx_kit/readme.md. The core SDK components do not use this library, but it is widely used in the helper code and samples.

Build your plugin

The standard method to build plugins is to run the sample build script included with the SDK:

• Linux or Cygwin: Run ./build_samples.sh

• Windows: Run build_samples.bat

Verify that you can run the build script successfully before moving to an Integrated Development Environment (IDE) or custom toolchain.

Once the script builds successfully, you can transition to your preferred development environment. Popular setups include:

• Command-line CMake with a text editor like Visual Studio Code, Vim, Emacs, or Notepad++.

• An IDE such as CLion, Visual Studio, or Qt Creator.

To transition to an IDE, review the console output of the build script to see the commands executed during the build process. You can also inspect the build script source code to understand how it compiles the samples, and then try running those commands manually.

Cross-platform considerations

The SDK and its samples are cross-platform and support Windows, Linux, and cross-compilation for ARM-based devices. If you choose to make your plugin cross-platform, you must write platform-agnostic code and test it on each targeted operating system.

The SDK and samples use C++14 features and do not require external dependencies. Your plugin can use higher language standards, such as C++17 or C++20, which offer built-in standard library features for file system navigation, multi-threading, and regular expressions. You can also use popular cross-platform libraries like Boost or Qt.