Uwe Ohse

Quark

Mailboxsystem tom/Quark: nicht mehr!

• Als Datenbankformat wurde MausTauschformat gewählt. Das geschah aus Geschwindigkeitsgründen und weil die Box eine MausTauschbox sein sollte - andere Formate zu verstehen war nie das Ziel.
  Das ist natürlich heute hinfällig: Moderne Prozessoren sind denen von 1992 weit überlegen und könnten problemlos on the fly das Format konvertieren. Daher könnte man in der Datenbank ein leistungsfähigeres Format verwenden: RFC-Technik, mit der man dann Zugriffe durch heutige Standardtools erlauben könnte.
  Das gilt umsomehr als die reine Geschwindigkeit niemals ein wirkliches Killerargument gewesen ist (im Gegensatz zu unseren Hoffnungen).
  Leider sah` die Welt 1992 noch anders aus: die Newsserver waren alle krankhaft langsam, und das Mbox-Format hatte keine ernstzunehmende Alternative. RFC-Technik schien uns auch zu kompliziert zu sein - was sie auch ist: RFC822 ist grausam. Wieviel mehr Möglichkeiten diese Technik bietet und um wieviel besser sie weiterentwickelt werden würde war nicht abzusehen (jedenfalls für Anfänger).
• Die Geonetoberfläche - Grundlage des Onlinebenutzerinterfaces - ist heute bedeutungslos. Das an sich wäre nicht schlimm wenn nicht die alternative Mausoberfläche direkt darauf sitzen würde. Wer immer die Geonetoberfläche renoviert darf auch parallel dazu den TCL-Code ändern. Die richtige Lösung wäre gewesen eine weitere Zwischenebene zu schaffen auf der Geonet- und andere Oberflächen gemeinsam aufsetzen (damit wäre dann auch das Problem unpassender Geonetfehlermeldungen in der Mausoberfläche sauber lösbar gewesen).
• die Quark ist ein einziges großes ausführbares Programm. Als wir anfingen, zu Atarizeiten, war das ausführen externer Programme relativ kostspielig, die Kisten waren damals langsam genug. Außerdem ist die Quark II aus einer "Basic nach C"-Übersetzung entstanden, und wenn auch keine Codezeile unverändert blieb: Die grundlegende Struktur der Software war ähnlich.
  -> Manchmal ist es besser ganz neu anzufangen.

• Apropos Funktionstest: ein Folgeproblem der Philosophie "alles-in-einem-Programm" ist daß man nicht kleine Teile auf Korrektheit prüfen kann - das große interaktive Monster "quark" ist gegen alle Arten automatischer Tests weitgehend immun, inbesondere dank der Tatsache daß noch an genügend Stellen Binärdateien verwendet werden. ASCII-Dateien sind weitaus einfacher zu vergleichen (so Dinge wie timestamps in Binärdateien zu bereinigen ist deutlich aufwendiger).
  Beim Nachrichtenhandling wären automatisierbare Tests aber sehr von Vorteil ...
• Header-Envelope-Trennung ist nur rudimentär vorhanden. Vorhanden ist sie schon - bis die Nachricht die Quark verläßt.
  Als Entschuldigungen lassen sich nur anführen daß wir es damals nicht besser wußten, MAUS es sowieso auch nicht konnte und derartige fundamentale Fehler schwer nachträglich zu bereinigen sind.
• An vielen Stellen haben wir uns an der Konkurrenzsoftware orientiert. Klingt gut? Klingt es auch noch gut wenn man schreibt technisch veralteter Software? Als Entschuldigung sei gesagt daß man nichts davon hat wenn man besser ist - MAUS läßt einen nicht.
• Quarkreleases fertig zu machen dauert ein bis zwei Tage. Der aufwendige Teil ist, die Software auf irgendeinem anderen (vorzugsweise nicht Linux) System zu compilieren ... dabei rennt man dann üblicherweise in das Problem automake und autoconf updaten zu dürfen, und wenn auch alle Einzelschritte eher trivial sind und man nebenher - wenn gerade der 25. Compilerlauf auf der langsamen Kiste zugange ist - auch gut Tee trinken kann: Zeit frißt es trotzdem.
  Ärgerlicherweise gelingt es mir dennoch nicht sicherzustellen daß sie auf allen Systemen reibungslos compilier- und installierbar ist. Das ist sie noch nicht mal auf allen Linuxsystemen, und die Ursache sind diverse kleine Systemabhängigkeiten, beispielsweise bedingt durch den curses/ncurses-Wahnsinn mit der Verwirrung bei Headerdateien (curses.h, ncurses.h, ncurses/ncurses.h etc), schief installierten Libraries (libcurses.a mit dazugehöriger ncurses.h) oder Systemen mit installierten curses- und ncurses-Libraries, bei denen die curses tatsächlich neuere ncurses sind.
  TCL bereitet ähnliche Probleme.

  Langfristig besser wäre es gewesen rechtzeitig das ganze Terminalhandling neuzuschreiben und irgendeine Ersatzlibrary zu verwenden - "für die Quark brauchst Du libXXX Version y bis z, andere tun nicht" läßt sich leichter verschmerzen (wenn die Quark das einzige Programm ist was libXXX braucht, was bei solchen Libraries hinreichend sicher ist) als "ncurses-1.9d? Nein, nimmt c. Ach, geht nicht wegen dem und dem? Dann ändere doch die und die Zeile in den Quarksourcen". Problem dabei: Die Ersatzlibraries gab es damals nicht - deren Programmierer mußten erst genug gefrustet über die curses sein um loszulegen.
  TCL zu verwenden war sowieso ein Fehler: Die Syntax von TCL ist zu abartig. Und TCL ist zu groß, zu fett (was noch mehr auf Perl zutrifft). Vernünftigerweise hätte man etwas einfacheres genommen. Heute gibt es Alternativen - damals waren die allerdings noch dünn gesät.
  

• Ein kapitaler Fehler war, im Nachhinein, die Sourcen so zu strukturieren wie es geschah: Unterverzeichnisse mit unabhängigen Makefiles für verschiedene logisch unabhängige Teile der Sourcen.
  make ist ein gutes Tool, aber ein Makefile kennt nicht die Abhängigkeiten die ein Anderes verwaltet. Anders gesagt: Es wird nicht notwendigerweise immer alles neu gemacht was neu gemacht werden sollte. Jedes Makefile tut was man ihm sagt, aber das war's dann auch schon.
  Zusammen mit einem automake-Mißfeature (Stand: Version 1.3) kann das ganz häßliche Probleme bereiten: automake generiert die Dependency-Dateien nicht neu wenn sie verschwunden sind. Zwar kann man automake leicht dazu bringen die .deps/irgendwas neu aufzubauen, aber das Problem muß man erstmal bemerken.

  Ich habe viel Zeit auf der Suche nach derartigen Probleme verbracht: "ich hab' das doch gerade geändert - wieso passiert immer noch dasselbe?". Kurz ins Verzeichnis "lib" gegangen, etwas geändert, make aufgerufen. Klar, ich hätte das Make im Toplevelverzeichnis aufrufen sollten. Nur hab' ich nicht - und das passiert zu leicht.
  

• In der DU3 macht die Datenbank Probleme. Ich habe dort einen einen ziemlich hohen Crosspostinganteil in der Datenbank, und die ziemlich uralte Datenbankversion ist damit schlicht überfordert, der Putz dauert manchmal eine halbe Stunde. Franks neuere Datenbankversion ist aber nicht so weit daß er sie mir empfehlen mochte.
  
• Das Jargon-File beschreibt es ganz gut:

  :creeping featurism: /kree'ping fee'chr-izm/ n.

  1.

  Describes a systematic tendency to load more {chrome} and {feature}s onto systems at the expense of whatever elegance they may have possessed when originally designed. See also {feeping creaturism}. "You know, the main problem with {BSD} UNIX has always been creeping featurism."

  2.

  More generally, the tendency for anything complicated to become even more complicated because people keep saying "Gee, it would be even better if it had this feature too". (See {feature}.) The result is usually a patchwork because it grew one ad-hoc step at a time, rather than being planned. Planning is a lot of work, but it's easy to add [...]

  Längere Zeit lang wurde jedes irgendwie nützlich erscheinende Feature eingebaut (zum allergrößten Teil mein Fehler). Dementsprechend groß sind die Sourcen jetzt. Und dementsprechend wartungsunfreundlich: Jedes Feature mehr muß weiter funktionieren, und steht oft genug auch Sourceaufräumaktionen im Weg.
• eine Abart von not invented here ist darauf kann ich mich nicht verlassen. Der Wunsch, die Quark möglichst portabel zu halten, ist (IMNSHO) deutlich zu weit getrieben worden: Wir hätten den internen getty längst beseitigen sollen, und das Eventhandling und ähnliche Features die Systemdienste übernehmen könnten, gleich mit dazu.
  Da wir uns nie darauf verlassen konnten daß das System (Atari, dann OS/2, später NT) dieses Feature auch bietet haben wie den entsprechenden Teil dann selbst geschrieben.
  Die spezialisierten Programme, die wir nicht benutzen konnten, haben ihren Job aber meist sehr gut gemacht. Und bieten manchmal auch viel mehr. Und wo sie etwas nicht boten wäre es sinnvoller gewesen sie aufzubohren als sie zu ersetzen.
  Daß wir die angestrebte Kompatibilität zur Welt außerhalb von Unix nicht erreicht haben birgt eine gewisse Ironie.
  Warum wir sie nicht erreicht haben? Weil wir das nie wirklich ernsthaft voran getrieben haben, Ports blieben immer im Spielstadium: So haben dafür viel verschwendet ohne daß ein echter Nutzen entstanden wäre.
• Mangelnde Kapselung ist ein weiteres Problem: So ist die Kapselung der Datenbank nicht so schlecht wie in gewisser anderer Software, aber auch bei weitem nicht so gut daß es einfach wäre eine ganz andere Datenbank zu verwenden.
• Die Software verwaltet viel zu viele Daten. Wir schleppen einen Haufen Daten herum, erhöhen Zähler, etc, die niemand interessieren. Das hat teilweise historische Gründe.
• Außerdem gibt es viel zu viele Konfigurationsmöglichkeiten: Um die 20 teilweise optionale Konfigurationsdatein, etliche boxspezifische Textdateien und >130 mögliche Konfigurationsvariablen in der Hauptkonfigurationsdatei. Ein Betreiberinterface aus der Hölle. Die Dokumentation hinkte immer hinterher.
• Ein unschönes Thema ist auch der Programmteil: Daß ich einen (zwei) Versuche gemacht habe einen zu entwerfen war Zeitverschwendung. Ein benutzbares Benutzerinterface bekomme ich nicht zusammen. Ich hätte die Energie besser dahin investiert andere Leute dazu zu bringen einen zu schreiben - zumal ich selbst nie Interesse an einem Programmteil hatte.
• Anderswo in der Welt ist die Entwicklung nicht stehengeblieben. Die RFC-Technik wird allgemein angewendet und es gibt Tausende Tools dafür - die eben auch Features bieten die man mit MausTauschtechnik nicht nachahmen kann (mal abgesehen davon daß man sie dann selbst nachahmen müßte, statt sie einfach zu verwenden).