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:
- 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 and a Q_DECLARE_INTERFACE macro). 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.
Deployment
Benefits
- Reduced Complexity
- Reuse
- Real World
- Easy Deployment
- Dynamic Updates
- Adaptive
- Transparency
- Versioning
- Simple
- Small
- Lazy
- Secure
- Humble
- Non Intrusive
