Commit f4990a34 authored by David Trattnig's avatar David Trattnig
Browse files

Logical structuring.

parent 5f1c8a93
......@@ -63,39 +63,32 @@ in the components diagram.
If you are interested in more technical details, check out the [Developer Guide](docs/development/index.md)
## Component spaces
## Getting started
So we have two *component spaces* for our architecture. Each space defines the nature of the components it holds
Currently we are not yet in a state where we could provide some simple
.deb packages or some kind of easy install script. So if you want to try it
out you will have to prepare for a little shell and config trickery. Also not
all components do provide all functionalities already. Here is a rough guide
on what to try. More info on the individual modules can be found in their
repos.
* **AURA Web** - Holds all the web applications, data store and media management
We suggest to set up the components as in the order above, as
they will partly only be insightful if they interact with each other.
Head over to to each project site. There you will also find a `README.md`
with all necessary infos for the setup:
* [Steering](https://gitlab.servus.at/aura/steering) - 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.
* [Tank](https://gitlab.servus.at/aura/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*.
* [Dashboard](https://gitlab.servus.at/aura/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.
| | [<img src="./assets/images/aura-steering.png" width="150" align="left" />](https://gitlab.servus.at/autoradio/pv) | [<img src="./assets/images/aura-dashboard.png" width="150" align="left" />](https://gitlab.servus.at/autoradio/dashboard) | [<img src="./assets/images/aura-tank.png" width="150" align="left" />](https://gitlab.servus.at/autoradio/tank) | [<img src="./assets/images/aura-engine.png" width="150" align="left" />](https://gitlab.servus.at/autoradio/engine) |
|---|---|---|---|---|
| **Component** | [Steering](https://gitlab.servus.at/autoradio/pv) | [Dashboard](https://gitlab.servus.at/autoradio/dashboard) | [Tank](https://gitlab.servus.at/autoradio/tank) | [Engine](https://gitlab.servus.at/autoradio/engine) |
| **Dependencies** | | Steering, Tank | Steering | Steering, Tank |
* [Dashboard Clock](https://gitlab.servus.at/aura/dashboard-clock) - A modern studio clock.
The whole _AuRa_ infrastructure is super flexible in the way it can be setup,
that's why we have started compiling a very opinionated [Installation Guide](docs/administration/installation-guide.md).
* **AURA Play-out** - Everything what's needed to turn data into sound
* [Engine Core](https://gitlab.servus.at/aura/engine) - this is where the schedule is actually translated into some stream of sound, our play-out server. It is responsible for playing the right audio at the planned times.
* [Engine Control](https://gitlab.servus.at/aura/engine) - the place where the actual scheduling happens. A remote control for Engine Core.
There is also an _AuRa_ demo setup hosted by https://o94.at. In case you are
interested for a trial-run, please get in touch.
* [Engine API](https://gitlab.servus.at/aura/engine) - this is where the schedule is actually translated into some stream of sound, our play-out server. It is responsible for playing the right audio at the planned times.
## Read more
## Getting started
* [User Guide](docs/user/index.md)
* [Installation Guide](docs/administration/installation-guide.md)
* [Maintenance Guide](docs/administration/maintenance-guide.md)
* [API Specification](docs/development/api-definition.md)
* [Conflict Resolution](docs/administration/conflict-resolution.md)
* [Installation Guide](docs/administration/installation-guide.md) ([Installation Guide](docs/administration/installation-guide.md), [Maintenance Guide](docs/administration/maintenance-guide.md))
## Contributors
......
......@@ -3,6 +3,13 @@
# Administration Guide
Currently we are not yet in a state where we could provide some simple
`docker-compose up` nor proper maintenance scripts. But [we are working on it](https://gitlab.servus.at/aura/meta/-/issues/56).
So if you want to try it out you will have to prepare for a little shell
and config trickery. Also not all components do provide all functionalities
already. If you choose this path, then the [Developer Installation](../development/index.md) is your way to go.
1. [Administration Guide](#administration-guide)
1. [Planning your integration](#planning-your-integration)
2. [Installation](#installation)
......
......@@ -7,6 +7,7 @@ This guide holds all general information for AURA developers. For more specific
1. [Developer Guide](#developer-guide)
1. [Architecture](#architecture)
1. [Architecural overview](#architecural-overview)
2. [Component spaces, components and dependencies](#component-spaces-components-and-dependencies)
2. [Installation](#installation)
3. [Development](#development)
1. [Coding Conventions](#coding-conventions)
......@@ -15,7 +16,7 @@ This guide holds all general information for AURA developers. For more specific
4. [Simplified Data Model](#simplified-data-model)
5. [AURA CLI](#aura-cli)
6. [AURA API](#aura-api)
7. [Conflict Resolution for Timetable](#conflict-resolution-for-timetable)
7. [Conflict Resolution for the timetable](#conflict-resolution-for-the-timetable)
4. [Planning](#planning)
1. [Sprint Planning](#sprint-planning)
2. [Planned Versions and Release Criteria](#planned-versions-and-release-criteria)
......@@ -33,7 +34,7 @@ This guide holds all general information for AURA developers. For more specific
### Architecural overview
Some of our core organisational and architectural requirements for _AuRa_ are:
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
......@@ -47,16 +48,24 @@ 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:
### Component spaces, components and dependencies
* [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.
We suggest to set up the components as in the order above, as
they will partly only be insightful if they interact with each other.
Head over to to each project site. There you will also find a `README.md`
with all necessary infos for the setup:
* [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.
| | [<img src="./assets/images/aura-steering.png" width="150" align="left" />](https://gitlab.servus.at/autoradio/pv) | [<img src="./assets/images/aura-dashboard.png" width="150" align="left" />](https://gitlab.servus.at/autoradio/dashboard) | [<img src="./assets/images/aura-tank.png" width="150" align="left" />](https://gitlab.servus.at/autoradio/tank) | [<img src="./assets/images/aura-engine.png" width="150" align="left" />](https://gitlab.servus.at/autoradio/engine) |
|---|---|---|---|---|
| **Component** | [Steering](https://gitlab.servus.at/autoradio/pv) | [Dashboard](https://gitlab.servus.at/autoradio/dashboard) | [Tank](https://gitlab.servus.at/autoradio/tank) | [Engine](https://gitlab.servus.at/autoradio/engine) |
| **Dependencies** | | Steering, Tank | Steering | Steering, Tank |
* [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*.
The whole _AuRa_ infrastructure is super flexible in the way it can be setup,
that's why we have started compiling a very opinionated [Installation Guide](docs/administration/installation-guide.md).
There is also an _AuRa_ demo setup hosted by https://o94.at. In case you are
interested for a trial-run, please get in touch.
* [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
......@@ -121,9 +130,9 @@ Then it is recommended to configure the projects in following order:
*to be defined*
### Conflict Resolution for Timetable
### Conflict Resolution for the timetable
*to be defined*
Check out the [Conflict Resolution](../administration/conflict-resolution.md) page.
## Planning
......
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