Ataquarium - TORG

Die Sommerpause naht und auch der Coldfire-Atari rückt immer näher. Daneben gibt es interessante Software-Projekte, die vor kurzem angeschoben oder aus der digitalen Gruft gehoben wurden.

Oliver Landemarre widmet sich dem sträflich vernachlässigten Gebiet der Web-Browser und präsentiert mit Gulliver [1] einen Browser, der auf dem Datenblatt HighWire ähnelt. Gleichzeitig präsentiert Patrice Mandin sein Dillo-Konvertierung [2]. Jetzt kann nur gehofft werden, das nicht ähnlich wie bei den TCP/IP-Stacks jeder Programmierer auf die Idee kommt, einen eigenen Web-Browser zu programmieren. Da ist schon die Frage berechtigt, ob der Atari-Markt nicht ganz andere Software-Lücken hat wie wäre es z.B. mit einem Flash-Player [3]?
Das zweite Projekt hat auch etwas mit Hypertexten zu tun. Philipp Donzé hat einen ST-Guide-Clone [4] programmiert, der nicht nur moderner aussieht, sondern auch mit hohen Farbtiefen keine Probleme hat. Ob das HYP-Format trotzdem eine große Zukunft hat, steht aber noch nicht fest.

Ebenfalls schon mal in einer anderen Form dagewesen, aber in einer modernen Fassung nicht unerwünscht, ist die STE-FAQ von Paranoia [5]. Die FAQ wurden zusammengestellt nach deprimierenden Stunden voller Experimente und Tests, die dann doch nicht das gewünschte Ergebnis brachten. Die Stolperfallen die der STE bietet, möchte das ca. 62 KB große Dokument aufdecken, damit andere Programmierer vorgewarnt sind. Allerdings werden in dem Dokument auch der Falcon und TT angesprochen. Die Themen im FAQ sind unter anderem Hardware-Scrolling, Split-Screen, Blitter, DMA-sound, Microwire-Interface, die erweiterten Joystickports, MegaSTE und Falcon/TT-Kompatibilität. Für jeden, der Englisch kann und sich etwas mit dem STE beschäftigen möchte/muß, eine sicherlich empfehlenswerte Lektüre.

TOS-Group

Einige Standrds wurden bereits von der TOS-Group beschlossen, immer kommentiert mit einem dramatischen Project is deleted vom News-Robot. Ein TORG definiert einen Standard, an den sich möglichst alle halten sollten. Von diesen beschlossenen Standards gibt es, ohne die TORGs, die das Aussehen von TORGs definieren, fünf. Das ist nicht besonders viele und da das Schreiben eines TORGs für viele noch ein Buch mit sieben Siegeln zu sein scheint, soll diesmal erklärt werden, wie ein TORG geschrieben wird.

Die Idee

Zuerst wird natürlich eine Idee benötigt. Standardisiert werden kann vieles, es könnte z.B. auch jemand ein TORG über die Standardbreite von Dialogboxen schreiben. Der Einfachheit halber und weil das Thema im alten TOSGroup-Forum breit diskutiert wurde -, wird Standards für Anleitungen ausgewählt. Im alten Forum hat Robert Schaffner das Thema aufgebracht.

Text

Ein TORG ist ein ganz normales Textdokument im ASCII-Format und kann somit mit jedem Text-Editor geschrieben werden. Um Darstellungsprobleme auf verschiedenen Computern zu vermeiden, wird ä, ö, ü durch ae, oe, ue ersetzt.
Ferner sollte das TORG mehr enthalten als eine bloße Willenserklärung wie zum Beispiel MagiC soll Standard sein. Wichtig ist eben auch, warum MagiC Standard sein soll. Das TORG, das eingeschickt wird, bildet die Diskussionsgrundlage, aus der Diskussion entsteht wiederum das endgültige Dokument, über das abgestimmt wird.
Um bei dem Thema Anleitungen zu bleiben: Vorgeschlagen wird HTML als Standard für Anleitungen. Ein paar Gründe, warum es den ST-Guide ersetzen sollte, müßten schon ausgeführt werden:

HTML ist plattformübergreifend Standard
die Syntax ist jedem vertraut
...

Ein TORG sollte seine Absichten also immer begründen. Die genaue technische Verfahrensweise kann auch im TORG vorkommen, das TORG 105 Mausradprotokoll ist ein gutes Beispiel dafür. Was sich im gewählten Thema dafür anbietet, soll später erläutert werden, erst einmal folgen ein paar Formalia.

Formalitäten

TORGs sehen sich alle sehr ähnlich und werden nach einem bestimmten Muster erstellt. Dies vereinfacht es für die Leser, sich in neuen TORGs gleich zurecht zu finden.
In der ersten Zeile steht der Name der Gruppe (linksbündig) und der Name des TORG-Autors, also in meinem Falle:

TOS Standards Group     Matthias Jaap

In der nächsten Zeile steht die TORG-Nummer. Die TORGs sind fortlaufend numeriert, um eine frei Nummer zu finden, genügt ein Blick auf die TOSgroup-Hauptseite. Zur Drucklegung war die Nummer 106 noch frei, die wie folgt notiert wird:

TORG 106

In der nächsten Zeile folgt rechtsbündig das Datum des TORGs. Die Angabe des Monats und des Jahrs genügen:

Juni 2002

Jetzt werden am besten zwei oder drei Leerzeilen eingefügt, um den Kopf des Dokumentes etwas vom Rest abzusetzen. Der Titel des Dokuments folgt nun zentriert:

Standards bei Anleitungen

center

Nach dem Titel folgt der Status des Textes. Der Status ist zum einen eine etwas ausführlichere Erläuterung der Überschrift und zum anderen bestimmt er, ob die Verbreitung des Textes irgendwelchen Einschränkungen unterliegt. Dies ist bei den derzeitigen TORGs nicht der Fall, so das der Status lautet:

Dieses Dokument schlaegt ein Standard-Hilfsformat für Hilfsdateien auf dem Atari vor. Es ist offen zur Diskussion und fuer Verbesserungen. Die Verteilung dieses Protokolls ist unbegrenzt.

Wenn Sie sich einmal die anderen TORGs zur Gemüte führen, werden sie sehen, das im Status und bei der Copyrightanweisung am Ende des Dokuments eigentlich immer die gleichen Texte vorkommen. TORGs orientieren sich an offiziellen Dokumenten wie den RFCs.
Nach dem Status folgt eine kurze Copyright-Notiz, bei der eigentlich nur ggf. das Jahr zu ändern ist:

Ab jetzt folgt der Inhalt, d.h. Beschreibung des anvisierten Standards. Je nach gewähltem Thema kann dies mehr oder weniger technisch ausfallen. Ein eher technisches TORG ist die Beschreibung zur Unterstützung von Mausrädern. Martin Elsässer beschreibt, welche Systemaufrufe erweiterten werden sollten. Es muß aber nicht derart ins Details gegangen werden, die Beschreibung eines Standard-Internetzugangs listet auch nicht Aufrufe auf, die jeder TCP/IP-Stack können muß.

Damit sich der Leser im TORG zurechtfindet, wird ein kleines Inhaltsverzeichnis angelegt unabhängig von der Größe des TORGs. Dieses enthält mindestens fünf Gliederungspunkte:

Einleitung
Beschreibung des Standards
Kontakt
Adresse des Autors
Volle Copyrightanweisung

Die Einleitung beschreibt den Ist-Zustand, seine Problematik und erwähnt kurz den Vorschlag, das heißt das eigentlich Anliegen des TORGs. Dieser Vorschlag ist die Überleitung zu Gliederungspunkt 2, Beschreibung des Standards. So sieht die Einleitung für das Anleitungsthema aus:

Seit einiger Zeit sind auf dem Atari die HYP-Dateien des ST-Guide Standard. Doch dieser Standard ist in die Jahre gekommen: er ist zeilenorientiert, erlaubt nur wenig Gestaltungsmöglichkeit und ist nur auf dem Atari zu finden. Andere Systeme haben schon längst auf HTML umgestellt. Der Vorschlag dieses TORGs ist das HTML-Format, um den Hilfe-Dateien die Flexibilität zu geben, die auf anderen Plattformen selbstverständlich ist. Es soll ferner beschrieben werden, wie die Übergangsphase vom alten zum neuen Hypertext-Format vor sich gehen soll.

Die Beschreibung des Standards ist gleichzeitig der umfangreichste Teil des TORGs. Sie ist keine bloße Aufzählung der Vorteile, sondern bildet den Hauptansatz zur Diskussion:

HTML soll als Basis für einen zukünftigen Standard bei Anleitungen dienen.

Um HTML auch auf kleineren Ataris in vernünftiger Geschwindigkeit darzustellen, wird HighWire so modifiziert, das nur ein Teil der HTML-Befehle interpretiert wird. HighWire dient als Grundlage, da es der derzeit einzige Atari-Browser mit offenem Sourcecode ist.

Da viele kleine HTML-Dateien auf der Festplatte zuviel Platz belegen würden, wird an einem komprimierten Hilfsdateiformat gearbeitet, das eine gängige Kompressionsart (gzip - .gz) nutzt. Vorbild sind die komprimierten Hilfsdateien von Windows (.CHM). Die Nutzung einer Standard-Kompression ermöglicht es möglichen Übersetzern einer Anleitung, einen Packer zu benutzen, um an die Einzeldateien zu kommen. Ein spezieller Atari-Hypertextcompiler wie der HCP ist nicht mehr erforderlich. Da durch die Verwendung der ZLIB in HighWire gzip ohnehin unterstützt wird, wird dieses Format als Standard-Kompression vorgeschlagen.

Als Grafikformat dient GIF, das (X)IMG-Format könnte sofern Nachfrage besteht und den Browser nicht aufbläht später unterstützt werden.

Der Browser wird im Gegensatz zum ST-Guide echte Tabellen und Frames unterstützen. Damit kann z.B. die Gliederung einer Anleitung immer eingeblendet bleiben.

Die Ansteuerung des Browsers kann über die ST-Guide-Kommandos erfolgen und über GEMScript.

Der Hypertextbrowser kann auch HYP-Dateien verarbeiten. Die Konvertierung ist nicht im Programm selber enthalten, da sie pro Hypertext nur einmal benötigt wird. Stattdessen wird ein Konverter automatisch gestartet.

Die Schnittstelle zum Hilfssystem sollte in einem weiteren TORG definiert werden, um z.B. auch Light of Adamas zu benutzen.

Die Weiterentwicklung des neuen Hilfssystems profitiert von der Arbeit der HighWire-Programmierer. So können Fehlerbereinigungen und neue Features eingebaut werden.

Mit den nötigen Erweiterungen ist das neue Hilfssystem etwa 120 KB groß. Für die kleineren Systeme (8 MHz STs) wird ST-Guide weiterhin seine Daseinsberechtigung haben. Da moderne Anwendungen auch höhere Anforderungen stellen, gilt Falcon-Geschwindigkeit als Maßstab. Diese scheint auch bei einem Großteil der Benutzer laut der letzten Umfrage vorhanden zu sein.

Eine Beschreibung kann natürlich immer erweitert werden. So fehlen in dieser Beschreibung die HTML-Befehle, die nicht unterstützt werden müssen. Es ist durchaus möglich, das nach der Diskussion das TORG nochmal überarbeitet wird. Speziell über dieses Thema wurde im alten TOSgroup-Forum schon viel diskutiert, so das einige Argumente aufgegriffen werden: Größe des Hypertextsystems, komprimierte HTML-Dateien...
Jetzt geht es an das Ende des Dokumentes und sofern der eigene Wohnort, Emailadresse und Homepage bekannt sind, dürfte dies kein Problem sein.
Der Gliederungspunkt Kontakt enthält nicht ihre eigene Email-Adresse, sondern eine der TOSgroup:

Um mit dem TORG-Herausgeber in Verbindung zu treten schicken Sie eine E-Mail-Meldung zu: "torgeditor@tosgroup.org".

Die eigene Kontaktadresse kommt erst unter Adresse des Autors. Dies ist quasi das Gegenstück zum Impressum und daher sollte zumindest Name, Anschrift und Email dort aufgeführt werden.
Gliederungspunkt Nummer 5, Volle Copyrightanweisung, wird am besten aus einem anderen TORG kopiert.

Das wäre es schon, nun ist das TORG fertig zum Einschicken.

Sprache

Generell ist es schon nett, das fertige TORG in die englische Sprache zu übersetzen. Dies setzt natürlich voraus, das gewisse Sprachkenntnisse vorhanden sind. Automatische Übersetzungen wie von dem berühmt-berüchtigten AltaVista Babelfisch sind absolut ungeeignet und am ehesten für Forumsbeiträge geeignet.
Bisher liegt kein TORG in französischer Sprache vor, aber es haben bisher auch nicht viele französische Programmierer in der TOSgroup teilgenommen.

Einschicken

Um ein TORG einzuschicken, wird auf der TOSgroup-Seite Projekt anmelden ausgewählt. Die Warnung, das die Textdatei mindestens 10 KB groß sein soll, braucht nicht ernstgenommen zu werden. Das TORG-Dokument zu dem Standardhilfsformat ist knapp 5 KB groß.
Was nun folgt, ist ein Automatismus: der RGF-Robot schickt eine Email mit einem geheimen Projektschlüssel. Dieser kann benutzt werden, um das Projekt zu verändern.
Das Dokument wartet nun darauf, von einem Administrator beguatachtet zu werden. Geht alles gut, betritt das Dokument die Diskussionsphase. Den Abschluß bildet schließlich die Abstimmung.

Ein paar Worte noch...

Die Idee zu dem TORG stammt von Robert Schaffner. Einige Anregungen wurden von den Forumsteilnehmern übernommen.
Das alte Forum kann unter [6] aufgerufen werden.

[1] http://olivier.landemarre.free.fr/gem/gulliver/
[2] http://membres.lycos.fr/pmandin/index_e.html
[3] http://www.openswf.org/
[4] http://home.tiscalinet.ch/donze/preview/index.html
[5] http://www.uni-mainz.de/~heuno000/projects/projects.html
[6] http://tosgroup.org/forum/index.php3

Mia Jaap

Aus: ST-Computer 07 / 2002, Seite 38

Links