Wie dem vorherigen Blog-Beitrag zu Prosody, Tor und NodeJS zu entnehmen ist, sind die Grundfunktionalitäten von SDIM bereits gegeben. Was nun noch fehlt ist das Gesicht von SDIM. Da wir keinen Einfluss auf das Erscheinungsbild der Chat-Clients haben, bleibt uns zum gestalterischen austoben nur die Weboberfläche. Diese muss zwei grundlegende Eigenschaften aufweisen:

  • Ein ansprechendes und selbsterklärendes Design, für eine möglichst hohe Benutzerfreundlichkeit
  • Einfachen Zugriff auf die wichtigsten Funktionen, um Konsolen-unerfahrenen Nutzern das Konfigurieren ihrer SDIM Instanz zu ermöglichen

Node.js und Meteor.js

Zu Beginn standen zwei Technologien zur Auswahl, auf die sich die Oberfläche stützen könnte: Meteor.js und Node.js. Beide Technologien setzen Server- und Client-Seitig auf Java-Script, unterstützen diverse Template-Engins, Datenbanken und Paketmanagement via npm. Die Ähnlichkeit rührt daher, dass Meteor auf Node aufbaut. Node ist eine JavaScript Laufzeitumgebung die vor allem für ihr Leichtgewichtigkeit, Effizienz und Vielfältigkeit bekannt ist. Meteor will auf diesen Eigenschaften aufbauen und einige Dinge für die Entwicklung von Webanwendungen erleichtern. Zum Beispiel bietet Meteor bereits eine konfigurierte MongoDB, ein eigene Template-Engine und simple Funktionen um Daten vom Server zum Client (und andersherum) zu transportieren. Besonders stolz ist das Meteor-Team auf eines ihrer Key-Features: Wenn sich der Datenbestand der MongoDB ändert, passen sich alle verbunden Clients auf diese Änderung an, ohne dass zusätzlicher Code oder ein manueller Refresh vom User nötig ist.

Wenn Meteor im Prinzip nur Funktionen hinzufügt und die Entwicklung vereinfacht, warum haben wir uns dann für Node.js entschieden? Zum einen liegt dies am Konzept des Meteor-Teams ihren Lebensunterhalt zu finanzieren, zum anderen an den Nachteilen die ein System mit sich bringt, welches bereits ab Werk mit vielen Funktionalitäten beladen ist. Galaxy wird die Hosting Plattform (PaaS) von Meteor genannt. Dort können skalierende Webanwendungen mit einem Klick gehostet werden. Geht einfach – kostet viel. Da das Meteor-Team damit Geld verdient, haben sie ein gewisses Interesse Hosting auf anderen Plattformen nicht absichtlich einfach zu gestalten (ist jedoch möglich). Das Hosting auf einem RaspberryPi wird daher offiziell überhaupt nicht unterstützt. Bei unseren Tests haben wir auf diesen Fork des Meteor-Projektes zurückgegriffen. Meteor läuft damit zwar auch auf dem Pi, eine optimale Lösung ist das allerdings nicht.

Die endgültige Entscheidung fiel aufgrund der angesprochenen Nachteile. Eine vorinstallierte MongoDB Instanz ist schön – vor allem, wenn man sie benötigt. Dasselbe gilt für multiple Clients, die live auf neue Daten reagieren. Wir speichern unsere wenigen Settings jedoch entweder direkt in den Prosody/Tor/sonstigen Files oder in einem Web-Settings-File, und Zugriff auf die Weboberfläche wird in den meisten Fällen nur eine Person haben. Meteor gleicht für unseren Usecase damit einer überladenen proprietären Android Installation mit nicht benötigten Features, die langsam und schwerfällig ist.

Funktionen & Design

Unsere Weboberfläche besteht aus zwei Komponenten: Einem Einrichtungs-Wizard und einer Settings-Page. Der Wizard wird beim ersten Zugriff auf die Weboberfläche aufgerufen. Er soll den Benutzer durch die wichtigsten Einstellungen und Informationen führen und eine Lauffähige SDIM Instanz hinterlassen. Er ist in verschiedene Pages eingeteilt, die jeweils einen Aspekt der Einrichtung abdecken. Die Settings-Page bietet die Möglichkeit diese Einstellungen nachträglich anzupassen, den System-Log einzusehen sowie weitere Funktionalitäten.

 

Im Folgenden werden die wichtigsten Komponenten unserer Node-Anwendung aufgelistet:

  • Express (npm) als Node.js Framework
  • Handlebars (npm) als Template-Engine
  • Foundation 5 um das Gestalten zu vereinfachen
  • bcrypt (npm) zum sicheren Speichern/Lesen von kritischen Informationen
  • AJAX für den Großteil der Kommunikation (Cient -> Server)
  • socket.io (npm) um Logs „live“ an den Client zu senden

 

Der aktuelle Stand ist wie folgt: Der Wizard funktioniert, Settings werden geschrieben/gelesen, es können Scripts angestoßen oder direkt aus JavaScript Consolen-Befehle ausgeführt werden und der Log wird übertragen. Zurzeit arbeiten wir noch an dem Layout der Settings-Page sowie an Funktionen zum Verwalten der xmpp/jabber Benutzer.

SDIM: „Klickibunti“