Strategie arktur-5
Ursprünglicher Text: Erwin Flohr, 25jan07/26feb07
Strategieplan - Arkturteam
.
Die Situation
Die Entwicklung einer gänzlich neuartigen Arktur-Version ist aus mehreren Gründen nötig:
- Es besteht die Forderung nach einem technisch-neuen Systemunterbau der sich dann besser pflegen ließe.
- Die Bedienoberfläche, die Verwaltungsmechanismen, sowie die Konfiguration der Dienste sind bei den früheren Versionen ist im Laufe der Zeit innerlich immer komplizierter, unstrukturierter und inkonsequenter geworden, was die Fehleranfälligkeit und den Software-Wartungsaufwand erhöhte.
- Technische Dokumentation ist wenig vorhanden und sie ist undurchsichtig.
- Es wird ein klar gegliedertes System mit gut überlegten inneren Schnittstellen benötigt um arbeitsteilig daran weiterzuentwickeln zu können.
All das können die bisherigen Arkturi nicht bieten. Zwar wäre es möglich ihnen all das Fehlende einzuverleiben, jedoch würde kaum etwas vom alten Arktur übrig bleiben. Der Aufwand wäre größer als der bei einer vollen Neuentwicklung.
Um es mit den kuriosen Worten eines allgegenwärtigen Software-Hauses zu sagen: Es soll 'Neue-Technologie-Technologie' im zu entwickelnden Arktur enthalten sein. Auch jener Konzern musste in seiner Geschichte irgendwann die alten Zöpfe abschneiden, weil sie den neuen Anforderungen nicht gerecht werden konnten. Zunächst mal wäre alles über Bord zu werfen. Nur in sehr wenigen Einzelfällen wäre älter code zu übernehmen. Es ist andererseits eine äußerlich-oberflächliche Kontinuität und eine Beibehaltung der erfolgreichen Features von früheren Versionen gewünscht. Ein guter Teil der bisherigen Praxisanforderungen bleibt schließlich für die Zukunft mit Arktur-5 erhalten. Zudem sollen bisherige Systembetreuer und Betreuerinnen möglichst wenig umlernen müssen. Ganz leicht ist es nicht, innerhalb dieser Aufgabenstellung zu bleiben. Es müsste vorsichtig und mit Plan vorgegangen werden!
Auch die allgemeine EDV- und Internet-Entwicklung hat in den letzten Jahren nicht Halt gemacht. Die Anforderungen an ein Linux-basiertes System sind komplexer geworden, unterliegen zugleich hohen Sicherheitserwartungen und einer derart beschleunigten Weiterentwicklung, dass eine kleine Entwicklerinnengruppe diese Schritte für ein vielseitiges Serverpaket wie Arktur nicht mehr allein gehen kann. Es wäre notwendig, sich an die Arbeit namhafter Distributionen anzulehnen um auf ihre Vorarbeiten und auf ihren kontinuierlichen Support aufzubauen. Es würde allerdings erfordern, eine strikte Trennlinie zu legen, zwischen Schulserver-spezifischen Teilen und jenen Anteilen die in jedem gewöhnlichen Linux-System vorhanden sind. - Arktur *muss* dazu auf der Basis mindestens einer fremden Distribution elegant und dauerhaft aufsetzen (können). - Alle Arktur-unspezifischen Anteile sollten mit geringem Aufwand von einer anderen Distribution übernehmbar sein.
Je sorgfältiger und besser es gelingt, desto weniger Mühe würde für den Unterbau nötig sein. Die eingesparte Arbeitslast fließt dann gewiss in die Ausgestaltung der Arktur-Besonderheiten. Selbst die Entwicklung der Arktur-Qualitäten wäre nicht einfach. Auch hier stieg die Grenzmarke: Die Anforderungen im Alltagseinsatz der Schulen werden immer höher und zugleich differenzierter. Arktur muss immer mehr Leistung, für eine zunehmende Größe von Netzwerken, und für immer anspruchsvollere Dienste bieten. Allerdings sollte dem Fehler vorgebeugt werden, den anfänglich das Mozilla-Projekt beging. Dort wurde versucht mit einer geradezu monumentalen Software alle denkbaren Wünsche zugleich zu erfüllen. Das kann nicht gelingen. Zur Umgehung des Problemes wäre es zwar möglich das Arktur-Projekt in mehrere unabhängige aufzuteilen, die Sorgen daraus kennen wir jedoch schon jetzt genügend.
Problemlösungen schaffen, oder lieber lösbare Probleme schaffen?
Gegenwärtig sind sich die meisten Vordenker einig: Die beste Lösung, wenn nicht gar die einzig gangbare bestünde darin, Arktur modular zu gestalten. So könnten seine Eigenschaften für den jeweiligen Einsatzzweck gewandelt werden. Zudem wäre es möglich, auf veränderliche Bedingungen flexibel mit Erweiterungen oder mit Substitutionen von vorhandenen Modulen zu reagieren. Ein unschätzbarer Vorteil könnte es auch sein, dass die unabänderliche Fluktuation von Entwicklerinnen geringen Schaden für das Projekt verursacht. Schließlich müsste niemand bleiben der oder die für alle Teile von Arktur zuständig ist. Die modulare Teilung erfordert wenig Kompetenzträger die alles verstehen! Es bliebe nur ein kleiner Kern des Arktur in neuer modularer Technologie, für den sichergestellt bleiben sollte, dass er stetig von einigen Leuten verstanden und beherrscht wird.
Zur Klarstellung, Modularität heißt nicht einfach, dass Software auf schnellem Wege hinzugefügt oder ausgetauscht werden könnte. Das wäre schon mit einem Paket-Management möglich welches mittlerweile alle modernen Distributionen einsetzten (müssen).
Vielmehr bedeutet es, dass die Teile (Module) sich nahtlos einfügen können in den vorhandenen Aufbau: Sie müssen zu Kommunikation mit andren Teilen in der Lage sein, und das ungeachtet dessen, ob diese Teile bei der Entwicklung eines konkreten Modules bereits vorhersehbar waren! Sie müssen Anschluss finden können an einer einheitlichen Verwaltungsoberfläche, die ein neues Modul wiederum noch nicht kannte bevor dieses erschaffen war. Selbstverständlich muss die Dokumentation es ermöglichen an den betroffenen Stellen neue Abschnitte (automatisch, regulär) aufzunehmen, wann immer ergänzende Dokumentation für Module nötig wird. Gleiches gilt für die Kontexthilfe, wenn diese eine Themenverkettung quer über alle Module bieten soll.
Nötig wäre es, wohlüberlegte Schnittstellen für die einzelnen Komponenten zu spezifizieren. Es müssten zudem abstrakte Metaebenen definiert und implementiert werden, solche die nichts anderen tun, als zwischen den Modulen in immer identischer Weise zu vermitteln. Gleichermaßen erfordert und ermöglicht die Vereinheitlichung gemeinsame Funktionsbibliotheken und Visualisierungsmittel! Hier kann sehr viel Arbeit gespart werden. Eigene Tools für die Entwicklung der Arktursoftware lohnen plötzlich ihre Erschaffung, weil sie für eine große Anzahl von Modulen Implementierungs- und Testhilfe bieten. Die Aufzählung könnte weiter fortgesetzt werden, allerdings würde das abstrakte Bild unfruchtbar komplex.
Eine vergleichende Vorstellung von Modularität
Es lohnt sich ein Vergleich mit einer modernen grafischen Systemoberfläche, mit Gnome oder KDE (beides Linux), auch mit Aqua (Macintosh OS-X). Wer damit wenig Erfahrung hat, sollte unbedingt versuchen auf einem umfangreich ausgestatteten System testweise einen X-Server manuell zu starten und dem dann seine Oberfläche (wie aus der Requisitenkammer eines Maskenbildners) stückweise aufzusetzen. So lassen sich die Module, so lässt sich ihre relative Eigenständigkeit erkennen und manipulieren. Etwas das bei einem Desktop-Regelstart nicht so anschaulich ist. Eine einfache und detaillierte Anleitung findet sich in einem getrennten Text. Hier ist für dieses Extra-Thema nicht der richtige Platz.
Diese modernen Umgebungen sind hochgradig modular und integrativ konzipiert. Besonders weit geht dabei der window manager Enlightenment. Ganz wie der Name es umschreibt, wird der Präsentation und Funktion von Anwendungen dort so viel Vielfalt und Unterstützung geboten wie möglich. Ein window Manager versteht sich als *service pool*, der die Individualität und das Nebeneinander von Programmen fördert, ergonomisch und effektiv. Genau das sollte ein Arktur in der neuen Version anstreben.
Wie lässt sich einer Konkretisierung näher kommen?
Es gibt drei Seiten, von denen aus die Entwurfsarbeit zugleich angegangen werden könnte: Aus der Sicht auf die (1) Nutzungs- und Administrationsoberfläche, dann anhand der geforderten (2) Funktionalität bzw. der Dienste, zudem aus Richtung der zugrunde liegenden, paketweise erkennbaren (3) Systembasis. Damit wäre die zu erledigende Spezifikationsarbeit schon mal rundum eingegrenzt. Allein der 'leere Fleck' in der Mitte ist noch auszufüllen:
Punkt (1) ist am leichtesten vorstellbar. Es ist gewünscht, sich an das Aussehen bisheriger Arkturi anzulehnen und deren Bedien- und Kontrollmöglichkeiten mindestens gleich umfangreich bereitzustellen. Zusätzliche Oberflächeneigenschaften, die noch gebraucht werden, könnten aus der Praxis bzw. aus den Nutzerwünschen abgeleitet werden.
Punkt (2) richtet sich besonders stark nach äußeren Anforderungen technischer Art. Zu jedem Service den Arktur bieten soll wird es eine Begründung geben. Also gibt es bereits eine mehr oder weniger genaue Beschreibung der Eigenschaften, - womit die Client-Seite definiert wäre. Diese ist bereits als eine Sammlung von Spezifikationen anzusehen und ihr Gegenstück (auf Arkturseite) kann daraus abgeleitet werden.
Punkt (3) ist der am wenigsten gewisse. Welche ausgewählten Software-Pakete sollen die Basis bilden? Welche Linux-Distribution soll überhaupt die Auswahlliste aufbieten? Es wird häufig konkurierende Pakete geben unter denen das beste gefunden werden müsste. Teilweise wird nur ein bestimmter Versionsstand eines Basis-Paketes sich als gut geeignet erweisen (müssen). Es bestehen Abhängigkeiten der Pakete untereinander. Nicht alles könnte mit allem anderen gut kombiniert werden. Über die Zeit käme es gewiss laufend zu Änderungen. Und so bekämen wir laufend neue Prüf- und Entscheidungssituationen. Wir müssen das im Auge behalten! Zum Glück würde die gewählte Distribution aus der wir die Basispakete nehmen, uns mit einer riesigen, gut gepflegten Software-Datenbank und mit den üblichen Management-Tools Hilfe bieten. So würde sie uns die Arbeit sehr erleichtern.
Das Ausfüllen der Mitte in Arktur
Am besten würde es zunächst sein, sich sowohl von der Oberfläche, als auch von den Funktionsanforderungen aus zeitgleich vorzuarbeiten. Später, wenn erste Festlegungen gefunden sind, und ab da immer wieder, gilt es die best geeigneten Basis-Pakete zu finden und sie optimal zusammenzustellen. Dadurch würde dann klar, welche Arbeit noch bleibt für uns. Automatisch wäre alles was dem Team an Aufgaben bleibt das Besondere, *das Spezifische* an Arktur. Es würde das sein, was wir als von der universellen Linux-Basis strikt getrennt ansehen (müssen).
Die Oberfläche (1) soll eine bestimmte Bedienung ermöglichen. Dazu müsste sie ein entsprechendes Aussehen bekommen. Es gibt verschiedene Möglichkeiten diese Gestaltung zu erreichen. Wir werden das diskutieren. Oft würden wir einfach dem Designentwurf eines zuständigen Team-Mitgliedes zustimmen (müssen), denn nur Weniges was besonders wichtig ist, kann von allen gemeinsam besprochen und entschieden werden. Ich hoffe alle Beteiligten sind dafür, dass Kooperation Vorrang hat vor Parität! Denn, einige Stimmen haben es schon besorgt erwähnt, wir hätten nicht genug Lebenszeit um 'Alles von Allen' bereden und machen zu lassen.
Wäre eine Gestaltung erstmal entworfen, so lägen bereits schon Ideen für deren Implementierung vor. Bei der Erörterung von Umsetzungsmöglichkeiten wird auffallen, in wieweit sich die Teilarbeiten ähneln. Es gäbe natürlich Überschneidungen! Also ist die logische Folge, über eine Strukturierung nachzudenken. Typische, häufig benötigte Mechanismen bzw. Oberflächengestaltungselemente, könnten/müssen in einer gemeinsamen Bibliothek zusammengefasst werden. Das alles klärt sich dann beinah wie von selbst.
Damit möglichst vieles unter Verwendung einheitlicher, einfacher Routinen implementiert werden kann, wäre es angebracht Metaebenen zu definieren. Interne Schnittstellen. Aus vielen unterschiedlichen Halmen wird gewissermaßen ein gleich langer Rasen geschnitten. Erst dadurch kann der Ball der Ereignisse auf dem Feld prima rollen. Die Umsetzung unserer Gestaltungswünsche würde nach Definition dieser Grundlagen und durch Realisierung entsprechender Bibliotheksfunktionen fast ein Kinderspiel. Es lohnt, nochmal ein vergleichender Gedanke an die window manager für X. Dort geht es nicht anders. Wesentlicher Unterschied ist: unsere Aufgabenstellung wird viel einfacher zu lösen sein.
Die Art und Prägung der Serverdienste (2) ergibt sich aus den Bedürfnissen der user. Für viele Wünsche wird es bereits eine Teilspezifikation und vorgefertigte Pakete geben. Unsere wichtige Aufgabe bliebe aber: Wir haben für eine adäquate Konfiguration und vor allem für eine Integration in unseren Schulserver zu sorgen. Die Dienste müssen nämlich gesteuert werden, teilweise müssen sie zusammenarbeiten. Sie brauchen ihrerseits interne Dienste auf die sie zurückgreifen wollen. Erneut gilt: Das alles ergibt sich nahezu zwangsläufig aus der Art der services die Arktur 5 haben soll.
Jener Schritt, die Dienste selbst betriebsfähig zu machen, wäre also noch einfach. Der daran anschließende Aufgabenteil betrifft die interne Anpassung der öffentlichen Arktur-Dienste, die Initialisierung, die Überwachung, die Steuerung. Das würde schon schwieriger werden. Vor allem deshalb, weil eine nahtlose Berührung mit der/den Metaebene(n) unserer Oberflächenbausteine anzustreben ist. Beim Bearbeiten der einen Seite muss die andere schon in den Blick genommen werden. Beides ist aufeinander angewiesen. In der Implementierungsphase wird es zu wechselseitigen Einflüssen kommen (müssen). Alles Zusammen genommen, wäre das unser Entwicklungsprozess, den wir in kleinen gemütlichen Schritten gehen (werden).
Was mag an 'Gretchenfragen' bevorstehen?
Es folgt eine unvollständige Nennung von Entscheidungsfragen, die in gemeinsamer Beratung zu lösen sind:
- Wann und wo soll bei interner Kommunikation, bei Weitergabe und Speicherung von Parametern auf Datenstrukturen im XML-Format oder in anderen regulären Formaten zurückgegriffen werden?
- Sollen, wie sollen veränderliche Konfigurationsdaten gespeichert und verwaltet werden?
- Soll, was soll in einer LDAP-Datenbank abgelegt werden?
- Welche Linux-Basisdistribution bevorzugen wir?
- Welche grafische(n) Oberfläche(n) brauchen die user? Im Detail, welches Styling, welche Themes wollen wir?
- Wie, wo wird die Kontexthilfe eingegliedert?
- Auf welche Interpreter-Sprachen soll bei der Implementierung gesetzt werden?
- Wie sehen unsere Kodierrichtlinien aus, - soweit es welche geben soll?
- Wie gliedern sich die Arktur-spezifischen Teile in die Dateisystemstruktur ein?
- In wieweit gibt es verbindliche Variablennamen und normierte, systematisierte Konfigurationsoverlays?
Natürlich werden wir uns bei einigen Dingen ein bisschen streiten müssen. Das gehört wohl dazu! Auch sieht das alles nach einer ganzen Menge kaum lösbarer Aufgaben aus. Der Eindruck täuscht. Gerade wenn wir uns am Anfang etwas Zeit lassen, und in Ruhe an die Sache herangehen, wenn wir nicht gleich allzu lange 'Nägel mit Köpfen' machen (wollen), dann wird die Umsetzung eines fünften Arktur in Neuer Technologie schnell erledigt sein. Bestimmt haben wird damit mehr Freude und Erfolg als wir beim Aufsetzen einer typischen Systemumgebung des großen Bruders hätten.
Was in diesem Text fehlt
Neben dem oben angesprochenen (ausgelagerten) Exkurs zum X-Window Management fehlt weiteres. Konkrete Spezifikationsempfehlungen habe ich vermieden. Implementierungsanweisungen habe ich ebenfalls nicht formuliert. Die Themen gehören hier nicht her. Das bleiben Schritte die auf uns alle warten! Andere sind aufgerufen tiefer gehende Konzepte zu entwerfen, einzeln oder in kleinen Planungsgruppen.
