ACARS Hub NextGen

[fredclausen]

Introduction

This issue will be the roadmap and discussion area for ACARS Hub NextGen and it is a living document as the idea fully materializes. The current state of ACARS Hub, version v2, is a bit of a mixed bag. Functionally, it works well, but the code-base is very messy and difficult to continue improving the code and adding new features. Additionally, container setup is exceptionally difficult for new users and even experienced users re-setting up their system. Finally, development for anyone playing in the code is very slow because (re)building the container takes a very long time because of the non-layered approach under-taken so far.

At the very beginning of this project none of what it has morphed in to was envisioned. I had no idea so many people would download and enjoy ACARS Hub. I was a novice programmer (well, still am mostly, but I'm less green I suppose), and combined with the massive feature increase, design decisions were not thought out in a way that ensured it was "future proof". By having a "clean-slate" approach all of the above issues can be addressed.

At the conclusion of this project ACARS Hub v2 and prior will be End of Life with no further support or bug fixes.

The plan, in high level terms

• Have containers for each individual aspect of ACARS Hub NG (VDLM decoding, ACARS decoding, and the server)
• Rewrite the front end to fully encapsulate a more modular approach
• Create Electron or similar desktop app for viewing of ACARS Hub data

The Plan, in detail

Create docker images of common components

• Create the "SDR Common" base image
• Create a base image with common components for each SDR

Separate Containers

• acarsdec container
• vdlm2dec container
• dumpvdl2 container
• vdlm2dec container
• Remove decoders from main ACARS Hub container
  • Remove dumpvdl2
  • Remove acarsdec
  • Remove build deps of those containers
  • Remove startup scripts
  • Update Dockerfile
  • Update documentation

Back end updates

• Move database code to using "finally" and ensuring all sessions are closed
• Move DB pruning to in-code and not separate process (note: presently pruning in sep process may cause the DB to fail to write incoming messages, or fail to run a query, because the DB is locked outside of the main app. SQLite is not meant to deal with multiple processes accessing/writing data so we have to move this back under the watch of SQLAlchemy to avoid issues)
• Move FTS creation to in code and not a separate startup process
• Remove cont-init DB processing

Front end rewrite

Application

Misc

• Update GitHub Actions to use new acarshub-ng tag
• Set up linters for both pre-commit hooks and the CI on GitHub to be in sync
• Contributors/dev document