Commit 5f1c8a93 authored by David Trattnig's avatar David Trattnig
Browse files

Move architectur details to dev.

parent 30487edd
......@@ -49,30 +49,19 @@ Now we urgently need something new, and all those other solutions out there
Therefore we decided to pool our resources and develop something new, while
reusing a lot of work that has already been done at one or another stations.
## Architecural overview
## Architecural principles
Some of our core organisational and architectural requirements for _AuRa_ are:
* **modular architecture**: the whole suite should be made up of modular components which could be exchanged with other custom components
* **transparent API**: every component shall provide a well-documented API through which other components can interact with it, ideally as a REST API
* **reuse of existing components**: we do not want to reinvent the wheel. Several stations already developed single components as free software and we can adapt and build on those
* **modern frameworks**: we do not code from scratch but use modern application development frameworks which provide maintainability as well as security
* **Modular architecture**: the whole suite should be made up of modular components which could be exchanged with other custom components
* **Transparent API**: every component shall provide a well-documented API through which other components can interact with it, ideally as a REST API
* **Reuse of existing components**: we do not want to reinvent the wheel. Several stations already developed single components as free software and we can adapt and build on those
* **Modern frameworks**: we do not code from scratch but use modern application development frameworks which provide maintainability as well as security
Out of these requirements we came to an architecture which visually represented
in the components diagram.
![Diagram illustrating the AuRa components](https://gitlab.servus.at/autoradio/meta/raw/master/assets/images/components.png "AuRa Components")
So we have four AuRa components for our architecture which we codenamed _autoradio_. The following list depends the order of
dependencies and recommended installation:
* [Steering](https://gitlab.servus.at/autoradio/pv) - this is the scheduling module, where the actual program schedule of the whole station is stored as well as all infos regarding single shows and emissions. This module mainly acts as the administration interface, while most users will use *Dashboard* to get their work done.
* [Dashboard](https://gitlab.servus.at/autoradio/dashboard) - this is the frontend, were we get a good look on our shows and files to play. The interface aims for a simple experience and allows hundrets of people collaborating within the radio station. The module talks to *Steering* and *Tank* via OpenID, to retrieve program information as well as uploading audio files. Note the *Dashboard* itself has no data-store.
* [Tank](https://gitlab.servus.at/autoradio/tank) - just spleen without steam. Our tank is an importer module that is used to upload preprocessed emissions (audio data) and to streamline all audio so our _engine_ gets only the good stuff to power our radio channels. The module talks to *Steering* via OpenID to retrieves the current schedules. Additionally it delivers audio to the *Engine*.
* [Engine](https://gitlab.servus.at/autoradio/engine) - this is where the schedule is actually translated into some stream of sound, our playout server. It is responsible for playing the right audio sources at the right times and to record everything.
If you are interested in more technical details, check out the [Developer Guide](docs/development/index.md)
## Getting started
......
......@@ -5,8 +5,10 @@
This guide holds all general information for AURA developers. For more specific documentation please consult the individual `README.md` files in the relevant projects.
1. [Developer Guide](#developer-guide)
1. [Installation](#installation)
2. [Development](#development)
1. [Architecture](#architecture)
1. [Architecural overview](#architecural-overview)
2. [Installation](#installation)
3. [Development](#development)
1. [Coding Conventions](#coding-conventions)
2. [Network Diagramm](#network-diagramm)
3. [Component Diagramm](#component-diagramm)
......@@ -14,19 +16,48 @@ This guide holds all general information for AURA developers. For more specific
5. [AURA CLI](#aura-cli)
6. [AURA API](#aura-api)
7. [Conflict Resolution for Timetable](#conflict-resolution-for-timetable)
3. [Planning](#planning)
4. [Planning](#planning)
1. [Sprint Planning](#sprint-planning)
2. [Planned Versions and Release Criteria](#planned-versions-and-release-criteria)
4. [Release Managment](#release-managment)
5. [Release Managment](#release-managment)
1. [SemVer Versioning Scheme](#semver-versioning-scheme)
2. [How to do releases?](#how-to-do-releases)
5. [Contributing to AURA](#contributing-to-aura)
6. [Contributing to AURA](#contributing-to-aura)
1. [Code of Conduct](#code-of-conduct)
2. [Contribution Guidelines](#contribution-guidelines)
3. [Contributors](#contributors)
4. [Licensing](#licensing)
## Architecture
### Architecural overview
Some of our core organisational and architectural requirements for _AuRa_ are:
* **modular architecture**: the whole suite should be made up of modular components which could be exchanged with other custom components
* **transparent API**: every component shall provide a well-documented API through which other components can interact with it, ideally as a REST API
* **reuse of existing components**: we do not want to reinvent the wheel. Several stations already developed single components as free software and we can adapt and build on those
* **modern frameworks**: we do not code from scratch but use modern application development frameworks which provide maintainability as well as security
Out of these requirements we came to an architecture which visually represented
in the components diagram.
> Note: The following diagram doesn't reflect all the details of the current implementation. It will be updated at some point.
![Diagram illustrating the AuRa components](https://gitlab.servus.at/autoradio/meta/raw/master/assets/images/components.png "AuRa Components")
So we have four AuRa components for our architecture which we codenamed _autoradio_. The following list depends the order of
dependencies and recommended installation:
* [Steering](https://gitlab.servus.at/autoradio/pv) - this is the scheduling module, where the actual program schedule of the whole station is stored as well as all infos regarding single shows and emissions. This module mainly acts as the administration interface, while most users will use *Dashboard* to get their work done.
* [Dashboard](https://gitlab.servus.at/autoradio/dashboard) - this is the frontend, were we get a good look on our shows and files to play. The interface aims for a simple experience and allows hundrets of people collaborating within the radio station. The module talks to *Steering* and *Tank* via OpenID, to retrieve program information as well as uploading audio files. Note the *Dashboard* itself has no data-store.
* [Tank](https://gitlab.servus.at/autoradio/tank) - just spleen without steam. Our tank is an importer module that is used to upload preprocessed emissions (audio data) and to streamline all audio so our _engine_ gets only the good stuff to power our radio channels. The module talks to *Steering* via OpenID to retrieves the current schedules. Additionally it delivers audio to the *Engine*.
* [Engine](https://gitlab.servus.at/autoradio/engine) - this is where the schedule is actually translated into some stream of sound, our playout server. It is responsible for playing the right audio sources at the right times and to record everything.
## Installation
For Development the native installation as outlined in the `README.md` of each project is recommended.
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment