Documentation/CTK Plugin Framework: Introduction

Introduction to the CTK Plugin Framework

The CTK Plugin Framework can shortly be described as a dynamic component system for C++.

It's design is heavily inspired by OSGi (a dynamic component system for Java) and enables a development model where applications are (dynamically) composed of many different (reusable) components. This model allows to communicate through services, which are objects that are specifically shared between components.

The framework's layered model is illustrated in Figure 1, containing:

Figure 1: Layered Model of the CTK Plugin Framework

• Plugins - Plugins are the CTK components created by the developers.
• Services Layer - Connects plugins in a dynamic way by offering a publish-find-bind model for C++ objects.
• Life Cycle Layer - The API to install, start, stop, update, and uninstall plugins.
• Security - Handles security aspects (not available yet)

A more detailed explanation of these concepts can be found below.

Plugins

A CTK Plugin is, at it's core, a shared library based on the Qt Plugin system. Additionally, symbols in CTK libraries are by default hidden across all platforms. This is the first step towards modularity, which is about keeping things local and not shared. The less things you share, the less wrong assumptions can be made. However, without sharing there can be no collaboration. CTK Plugins usually only share symbols (classes and functions) to support the CTK services model.

Services

A collaborative model in C++ is usually realized with the use of factory patterns. Different toolkits use different patterns and API to access such a factory. Very often, influencing the decision about which implementation is used by the factory is non-trivial. Further, the implementation code can usually not advertise its availability, nor can the user list the possible implementations and pick the most suitable one. Factories are also in general not dynamic, once an instance of an implementation is registered, it can not be withdrawn. Finally, if many different factories are in use, there is no centralized overview of the implementations to which your code is bound.

One solution to these issues is the CTK service registry. A plugin can create an object and register it with the CTK service registry under one or more interfaces (an interface is a C++ class with usually only pure virtual methods). Other plugins can ask the registry to list all services (objects) that are registered under a specific interface. A plugin may even wait for a specific service to appear and then get a call back.

A plugin can therefore register a service, it can get a service, and it can listen for a service to appear or disappear. An arbitrary number of plugins can register services under the same interface, and any number of plugins can get the same service, see Figure 2.

Figure 2: Registering and getting a service

If multiple plugins register objects under the same interface, they can be distinguished by their properties. Each service registration has a set of standard and custom properties. You can use an expressive filter language to select only the services in which you are interested. Properties can also be used for other roles at the application level.

Benefits

• Reduced Complexity
• Reuse
• Real World
• Easy Deployment
• Dynamic Updates
• Adaptive
• Transparency
• Versioning
• Simple
• Small
• Lazy
• Secure
• Humble
• Non Intrusive