Atari-Insider: Dokumenten-Archäologie

Guten Tag, liebe Leserin und lieber Leser!
Diesen Monat werden wir uns mit der Vergangenheit diverser Dokumente beschäftigen, genauer gesagt mit der Liste der Dokumente, die der Benutzer zuletzt verwendet hat. So etwas bietet beispielsweise das MacOS im Apfel- Menü unter "Benutzte Dokumente" oder Windows in seinem Start-Popup. Seit etwas über einem Jahr steht mit dem "Document History Protocol" ein solcher Mechanismus auch für TOS-kompatible Multitaskingsysteme zur Verfügung. Mit StartMeUp! (SMU) wurde damals ein entsprechendes Protokoll eingeführt, und mittlerweile gibt es eine stattliche Anzahl von Applikationen, die das DHST-Protokoll unterstützen sowie weitere sogenannte DHST-Server (z.B. Multistrip), die die Dokumentenliste verwalten können.

Was Apple beim MacOS anbietet, kann so verkehrt nicht sein, also scheint eine solche Liste nützlich zu sein. Warum, sollte sich jedem schnell erschließen: Ein Anwender benutzt im Normalfall nicht sehr viele verschiedene Dokumente auf seinem Rechner (jeweils einige wenige aus den Bereichen Textverarbeitung, Tabellenkalkulation, Grafik - das war es dann auch meistens schon). An zentraler Stelle werden eben diese Dokumente automatisch gesammelt und können von dort leicht abgerufen werden.

Der DHST-Server kümmert sich also darum, die Dokumente samt zugehöriger Applikation zu speichern. Auf Benutzeranforderung startet er die entsprechende Applikation dann wieder (falls sie nicht läuft) und lässt sie das gespeicherte Dokumentladen. Und auch wer mit vielen Dateien arbeitet, hat immer noch den Vorteil, dass er beispielsweise beim nächsten Rechnerstart sofort die zuletzt verwendeten Dateien zur Verfügung hat, ohne sich erst durch tief verschachtelte Ordner wühlen zu müssen.

Natürlich kann man so etwas ähnliches auch mit Icons auf dem Desktop realisieren, aberdas wird schnell unübersichtlich (eine Liste ist da praktischer), und die Icons werden beim Laden der Dokumente meistens auch nicht automatisch auf dem Desktop abgelegt. Das DHST-Protokoll würde eine solche Lösung aber durchaus zulassen, und tatsächlich verwendet Multistrip Thing-Objektgruppen, die wie Verzeichnisfenster dargestellt werden können. Das Protokoll ist also so allgemein gehalten, dass es zwar die gewünschte Funktionalität zur Verfügung stellt, bei der Auswertung der Daten aber nicht zu sehr einschränkt.
Im folgenden werden wir uns zum einen damit beschäftigen, wie eine Applikation an das DHST-Protokoll angepasst wird, zum anderen gibt es ein paar überlegungen, wie ein DHST-Server im allgemeinen arbeiten sollte.

DHST-nutzende Applikationen

Es gibt verschiedene Situationen, in denen eine Applikation eine Datei an den DHST-Server melden sollte. Das ist zum einen immer dann der Fall, wenn der Benutzer das Laden eines Dokuments veranlasst (per Kommandozeile übergebene Dateien, Menüpunkt "Datei - öffnen...", Empfangen der AES-Nachricht VA START). VA START ist zwar nicht immer explizit vom Benutzer ausgelöst, doch können wir dies nicht unterscheiden, so dass wir alle VASTART-Nachrichten berücksichtigen müssen. Zum anderen sollten aber auch neue Dokumentnamen bei "Sichern als..." gemeldet werden. Bei "Sichern" selbst müssen wir dagegen nicht aktiv werden, da bei vorhandenen Dokumenten ein "öffnen" vorausgegangen sein muss und bei neuen Dokumenten "Sichern" als "Sicher als..." ausgeführt wird. Ein Beispiel, wann das Melden eines Dokuments keinen Sinn macht, sei auch noch erwähnt. Wenn der Anwender im Web-Browser CAB einen Link anwählt, wird dieser nicht gemeldet. Beim Surfen klickt der Benutzer oftmals viele Links an, mit denen er nicht wirklich "arbeiten", sondern die er "nur mal eben schnell" ansehen will. Würde CAB nun alle diese Dokumente (jede HTML-Datei ist ja aus Sicht von CAB ein Dokument) an den DHST-Server melden, wäre unsere Dokumentliste schnell überfüllt und sehr unübersichtlich - eine solche Liste nützt dem Anwender aber nichts mehr. Hier ist also weniger (Dokument-Meldungen) mehr (übersichtlichkeit).

Jedesmal, wenn eine der oben genannten Situationen zum Melden des Dokuments eingetreten ist, sucht die Applikation zunächst nach dem Cookie "DHST" (der Cookie Jar und das Prinzip der Cookies sollte den Lesern bekannt sein). Ist dieser vorhanden, steht im unteren Word des Cookie-Wertes die AES-ID des DHST-Servers, an den das Dokument gemeldet wird. Die Applikation legt nun im globalen Speicher folgende Struktur an:

typedef struct {
 char *appname,
      *apppath,
      *docname,
      *docpath;
} DHSTINFO;

In diese Struktur werden Zeiger auf Zeichenketten eingetragen, die natürlich
auch im globalen Speicherliegen müssen. Die DHSTINFO-Struktur selbst ist nur 16 Byteslang, beachten Sie also bitte, dass in der Struktur wirklich nur Zeiger und nicht etwa die Zeichenketten selbst stehen! Die einzelnen Zeichenketten sind wie folgt belegt:

appname: Name der Applikation (z.B."Texel")
apppath: absoluter Pfad der Applikation (z.B."C:\Programm\texel.app")
docname: Name des Dokuments (z. B."Berechnung von Pi")
docpath: absoluter Pfad des Dokuments (z. B. "D:\Daten\pi.txl")

Namen und Pfade werden unterschieden, damit der DHST-Server, der natürlich die genauen Pfade kennen muss, passende und "schöne" Namen anzeigen kann - beim Dokumentnamen kann das beispielsweise ein vom Benutzer vergebener Titel sein und braucht mit dem Dateinamen nicht unbedingt etwas zutun haben (das ist bei WebSeiten oft der Fall). Nun schickt die Applikation dem DHS T-Server folgende Nachricht:

**DHST_ADD
msg[0] 56029(Oxdadd)
msg[1] AES-ID der Applikation
msg[21 0
msg[3]

• Zeiger auf DHSTINFO-Struktur
  msg[4]
  msg[5] 0
  msg[6] 0
  msg[7] 0**

Als Antwort schickt der DHST-Server die folgende Message:

**DHST_ACK
msg[0] 56030 (Oxdade)
msg[1] AES-ID des DHST-Servers
msg[21 0
msg[3]

• Zeiger auf DHSTINFO-Struktur
  msg[4] (wie bei DHST_ADD übergeben)
  msg[5] 0
  msg[6] 0
  msg[7] 0=Fehler, sonst: OK**

Da sich der DHST-Server die Werte der DHSTINFO-Struktur selbst merkt, kann die Applikation diesen Speicher nun wieder freigeben. Das muss man auch dann machen, wenn der DHST-Server in msg[7] einen Fehler meldet. Da die Applikation nicht passend auf einen Fehler reagieren kann, braucht man den Fehlerwert nicht auswerten.

DHST-Server

Als Beispielimplementation eines DHST-Servers verwenden wir StartMeUp! ab Version 7.01. StartMeUp! zeigt die Dokumentenliste als Popup an, wobei der Name der zugehörigen Applikation in eckigen Klammern vordem Dokumentnamen ausgegeben wird (siehe Bild 1). Diese Liste wird beim (auch durch einen Shutdown ausgelösten) Programmende gesichert. Während in Version 7.01 einfach die letzten 15 Dokumente angezeigt wurden, kann man diese Zahl in Version 7.02 nun selbst bestimmen. Außerdem gibt es nun eine Maximalanzahl an Dokumenten pro Applikation (standardmäßig fünf). Wenn man also drei Texte in qed und anschließend 20 Rechenblätter in Texel lädt, werden die "alten" qed-Texte nicht aus dem Popup entfernt, da sich StartMeUp! nur die letzten fünf Texel-Dokumente merkt.

Andere DHST-Server können beider Verwaltung der Dokumente eine andere Systematik zugrunde legen. Ebenso sind noch einige Erweiterungen denkbar. So könnte die Zahl der Dokumente für Applikation separat festgelegt werden das wäre nützlich, wenn Sie viel mit CAB surfen, aber nur selten einen Text in qed bearbeiten. Die feste Maximalanzahl sorgt bei diesem Beispiel im Moment dafür, dass qed sein Kontingent nicht ausschöpft, während bei CAB auch oft benutzte Dokumente wieder aus der Liste verschwinden. Ebenso könnte sich der DHST-Server bei jedem Dokument merken, wie oft dies bisher schon benutzt wurde, und davon abhängig machen, ob das Dokument aus der Liste entfernt wird, wenn diese zu voll wird.

Es kann nur einen geben

Beim Start legt ein DHST-Server den Cookie "DHST" mit seiner AES-ID im unteren Word des Cookie-Wertes an (das obere Word wird derzeit einfach auf Null gesetzt). Nun kann es aber vorkommen, dass der Benutzer mehrere Programme automatisch starten lässt, die alle als DHST-Server arbeiten können. Und da es nur einen DHST-Server im System geben kann, gilt hier: Wer zuerst kommt, mahlt zuerst. Ein DHST-Server darf den Cookie nur dann anlegen, wenn dieser noch nicht existiert - ansonsten ist ihm ein anderer DHST-Server zuvorgekommen. Ebenso muss sich der DHST-Server merken, ob er den Cookie angelegt hat, denn nur dann darf bzw. muss er ihn beim Beenden auch wieder entfernen. Wenn noch kein DHST-Cookie existiert, dieser aber aus irgendwelchen Gründen nicht angelegt werden kann (z.B. weil der Cookie Jar ganz einfach voll ist), sollte dem Benutzer eine Warnmeldung ausgegeben werden.

Zu guter Letzt sollte der Benutzer bei Programmen, welche die DHST-Funktionalität nur nebenbei anbieten (das ist derzeit wohl bei allen DHST-Servern der Fall; ein eigenständiger DHST-Server ist mir nicht bekannt), festlegen können, ob sie überhaupt als DHST-Server arbeiten sollen. Damit kann man nämlich seinen einzigen DHST-Server explizit bestimmen, ohne dass man auf die Boot-Reihenfolge achten muss.

In StartMeUp! geschieht dies mit dem Schalter "/documents".
Wie üblich gibt es weitere Informationen und Links zu dieser Artikelserie im World Wide Web unter der Adresse http://www.snailshell.de/insider.html. Bis zu nächsten Monat!

DHST-Server:

• Multistrip
• StartMeUp!
• Taskbar

Thomas Much

---

---