3.1. Application Architecture

3.1.1. Implementation

The Configuration Tool is written in Python. This is a programming language that has support for a huge number of libraries and frameworks that allows Qualcomm to develop and modify this tool rapidly, and to enable a rich plugin mechanism that allows developers to extend the capabilities of the tool significantly.

_images/application_architecture.png

The architecture diagram above shows a number of noteworth features.

  1. The user interface to the Configuration Tool is built on top of Qt and Python bindings to Qt. This gives the application rich UI controls to improve the usability of the application.
  2. The data that the tool manipulates when the user is changing configurations is stored in a persistent object store that has ACID properties. This allows consistant data throughout the user interface without the user having to explicitly save at any point.
  3. Plugins are used to extend the capabilities of the tool, and these operate on classes defined in the application through a number of abstract interfaces. Any plugin can implement or override intances of these abstract interfaces, which allows plugins to perform multiple specializations. Plugins are explored further in the next section.

3.1.2. Plugins

A number of plugins ship with the standard install of the tool. Since Python is a dynamic programming language, a plugin is simply a Python package that conforms to some simple rules. Having done this, a plugin can override existing functionality, and implement new capabilities.

These are five major categories of functionality that plugins are most likely to want to implement.

  1. Chip families and variants. These are the areas that chip-specific plugins can change.
    • Configuration location. The major chip families will store their configuration information on-chip in very different formats and locations, and this class of plugin encapsulates this device-specific variantions.
    • Configuration specification. The actual data that needs to be configured - including the entire domain hierarchy - comes from these device-specific plugins. It’s up to the plugin how to store the cannonical configuration data: it could come from an XML file that passes through one of the format converter plugins described below.
  2. Connections to devices. Different chip families have different mechanisms for how the tool can connect to them and transfer configration data, and some chip families support multiple transports simultaneously. Plugins can define new strategies for these transport protocols.
  3. Format conversions. The data that represents the configurations can be converted to diffetent formats, and read back in again. For example, formats like XML or YAML can be supported.
  4. User interface theme. The theme and style of the user interface is very configurable, and a plugin can intercept calls for HTML, CSS and Image files to change the look of the user interface significantly.
  5. User interface interaction. Plugins can also override implementation of the user interface logic. For example it’s possible to change the default rendering of a configuration type to be something completely different.

Plugins are not restricted to providing just one these areas of functionality - a single plugin can implement any number it needs to.

3.1.3. Open Source Dependencies

In the spirit of:

Nanos gigantum humeris insidentes

(Standing on the shoulders of giants) this product is built on top of a number of awesome libraries that others have created and shared under various open source licenses. Here are the most notable ones:

  • Python. This application is written in Python, and in a sense everything depends on it. The portability, conciseness and expressiveness of Python makes it an ideal language for this sort of application. This is licensed using the Python License under the auspices of the Python Software Foundation (PSF).
  • PyQt5/PySide2/Qt. The Qt framework, and the PyQt5/PySide2 Python bindings to it, provide a rapid development environment when writing user interfaces in Python that are rich, powerful, and platform-independent. The PyQt5 bindings are licensed with a commercial license. The Qt libraries are used under the terms of the LGPL.
  • Zope Components. This framework provides a unique extension mechanism to enable plugins and disperate components to define interfaces to each other. This is licensed using the Zope Public License (ZPL) Version 2.1. The rich plugin architecture of the Configuration Tool is built on top of this framework.
  • Zope Database. This is an object-orientated database which makes persistence of Python objects fast, atomic and easy. This is also licensed with the ZPL 2.1. The device data that is configured in the Configuration tool is made persistent using this database framework. This data can be imported and exported to other formats, usually with the help of a plugin.
  • NSIS. The Configuration Tool Windows installer is built from this SDK. This is mostly licensed under a zlib/libpng style license.
  • Sphinx. This document is built using the Sphinx documentation framework, and it is licensed under a BSD license.

There are many other Open Source packages used in this product - both directly at runtime and indirectly in the development and testing phase of the product. See Open Source Licenses for the full list.