
.. _architecture:


Application Architecture
========================

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.

.. image:: _static/application_architecture.png
    :align: center

The architecture diagram above shows a number of noteworth features.

#. 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.

#. 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.

#. 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.


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.

#. 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.

#. 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.

#. 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.

#. 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.

#. 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.


Open Source Dependencies
------------------------

In the spirit of:

.. pull-quote::

    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)
  <https://www.python.org/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
  <https://en.wikipedia.org/wiki/Zope_Public_License>`_. 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
  <https://github.com/sphinx-doc/sphinx/blob/master/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 :ref:`open_source_licenses` for the full list.
