Seitenhistorie

Motivation

Für viele Entscheidungen und Abläufe benötigen wir Daten über unser Netz. Diese haben wir früher mittels A.L.F.R.E.D. erfasst, heute erfassen wir sie hingegen mittels repsondd. Wir sammeln diese Daten eigentlich nur im Kontext der Kartendarstellung. Dafür nutzen wir derzeit den hopglass-server. Jedoch haben wir eine Vielzahl an Anwendungen, die sich diese Daten nehmen und daraus andere Daten ableiten. Dazu gehören unter Anderem:

• node-stats: Brücke zwischen hopglass-server und Graphite / Temporale Erfassung von quantitativen Knotendaten
• node_hierarchy: Tool zur Optimierung der Firmware-Verteilung und Berücksichtigung von Abhängigkeiten (sowie ein paar Statistiken)
• geo_info: Knotenstatistiken nach geographischen Relationen
• node_stats.py: Script zur Ermittlung historischer Nutzerentwicklung
• ...

Problem

Bei der Vielzahl an Quellen und Anwendungen werden häufig viele gleiche (oder zumindest sehr ähnliche) Programmteile für jede Anwendung separat entwickelt. Bei Änderungen an den Daten / Datenstrukturen müssen in allen Programmen, teils sehr Umfangreiche, Änderungen vorgenommen werden. Obwohl der Inhalt der Daten meist gleich bleibt werden manchmal sogar ganze Programmteile obsolet bzw. erst erforderlich. Die Wartung dieser Anwendungen ist zum totalen Horror geworden.

Hopglass Server

Der hopglass-server (geschrieben in nodejs) verspricht prinzipiell eine Abhilfe in dem es (mehr oder weniger) modularisiert ist. Es gibt zwei Typen von Modulen: receiver (Datenakquisition, respondd, ...) und provider (Datenlieferanten, hopglass, meshviewer,...). Leider, dazu genügt ein flüchtiger Blick in den Quelltext, werden hier auch sehr viele Operationen redundant, und somit sehr wahrscheinlich auch inkonsistent, in den einzelnen Modulen gepflegt, obwohl sie auch generisch an einer Stelle im Code gelöst werden könnten.

...

Abschließend lässt sich noch anmerken, dass man beim Verwenden der hopglass-server Struktur an die Sprache nodejs gebunden ist.

Bisherige Datenstrukturen

Bisher werden die Daten bei der Erfassung in drei unterschiedlichen Typen geliefert:

...

Leider befinden sich bei Ersterem die Daten nicht immer dort, wo man sie erwarten würde. Bei Letzterem ist der Zugriff auf die Daten (zumindest bei graph) unnötig komplex (vermutlich dem Anstreben einer möglichst geringen Dateigröße geschuldet).

Anforderungen

Daraus lässt sich ableiten, dass die Verwaltung dieser Daten

...

Neben der eigentlichen Datenhaltung soll auch bereits eine Schnittstelle entwickelt werden. Diese soll einige, die für FFMS derzeit dringlichsten, Module enthalten. Die Entwicklung dieser Anwendung erfolgt aller Voraussicht nach in Python.

Entwurf

Konzeptionelle Ideen

Modularität

Die Entwicklung soll möglichst modular sein. Dazu wird an dieser Stelle eine mögliche Struktur der Module ausgearbeitet.

...

Anmerkung: Ausgegraute Punkte sind optional bzw. von niedriger Priorität.

Datenstrukturen

FIXME: Zunächst Dummy-Diagramme eingefügt. Werden noch ausgeführt.

Relationen

Datenbank

...