von Thomas Künneth
Inhalt:
Allgemeine Erläuterungen
Die beteiligten Nachrichten
Zum Schluß
Nachdem vor allem die letzte Folge dieser Artikelserie mit dem Inplace Drawing for OLGA (ID4) sehr komplexe Konzepte zum Gegenstand hatte, wollen wir uns diesmal mit etwas leichter verdaulicher - dennoch sehr schmackhafter, ähm, hilfreicher - Kost beschäftigen. Gegenstand näherer Betrachtungen wird die sogenannte Notification sein, ein Konzept, das ebenfalls mit der Version 1.2 Einzug in den OLGA-Manager hielt. Bevor wir uns mit der tatsächlichen Realisierung auseinandersetzen, soll zunächst interessieren, worum es hierbei überhaupt geht und wer von diesem Mechanismus profitiert.
Grob gesagt, teilt der Manager jeder OLGA-Anwendung (die Notification wünscht) mit, wenn eine andere am Protokoll teilnehmende Applikation eine Datei sichert. Wir müssen hier eine klare Trennung zwischen dem bereits diskutierten Client-Server-Konzept und Notification vornehmen. Bei letzterem handelt es sich nämlich um eine zusätzliche Instanz, die keineswegs in Konkurrenz zu bisherigen Funktionen tritt. Lassen Sie mich versuchen, dies mit einem konkreten Beispiel zu verdeutlichen. In der Dokumentdatenbank STELLA bewirkt ein Doppelklick auf einen Datensatz, daß mittels OLGA_START ein zur Extension der Datei (die der Datensatz repräsentiert) passender Server gestartet wird. Änderungen, die in der Server-Anwendung vorgenommen werden, veranlassen STELLA, ein evtl. vorhandenes Vorschaubild des Datensatzes sowie die Datei betreffende Informationen zu aktualisieren. Dies entspricht dem Ihnen bislang bekannten Client-Server-Modell. Was aber passiert, wenn der Anwender von sich aus in der Server-Anwendung eine neue Datei anlegt? Wünschenswert wäre doch sicher, daß STELLA dies erfährt und gegebenenfalls beim Anwender nachfragt, ob das neue Dokument vielleicht in eine Datenbank eingefügt werden soll.
Da für den Client (STELLA) diese Datei logischerweise nicht existiert (der Anwender hatte sie ja gerade eben erst angelegt), gibt es natürlich auch keinen Link auf diese Datei zwischen den beiden Programmen. Möchte der Anwender dieses Dokument nun in die Datenbank übernehmen, muß er es folglich selbst importieren. ... sehr umständlich, wie ich finde. Hier nun kommt Notification ins Spiel; der Manager bekommt mit, wenn Server eine Datei sichern (der Plural ist hier ganz bewußt gewählt), und schickt daraufhin eine spezielle Nachricht an STELLA. Die Zielanwendung (um wieder etwas allgemeiner zu werden) kann entsprechend reagieren.
Welche Aktion letztlich ausgelöst wird, ist natürlich in starken Maße von der Anwendung abhängig, die Notification wünscht. Natürlich wird man hier einwenden, daß ständiges Nachfragen beim Anwender nicht der Weißheit letzter Schluß ist. Diese Vorgehensweise diente denn auch eher der Veranschaulichung, warum Notification per se sinnvoll ist. Im folgenden Bild sehen wir ein gerade gesichertes Texel-Dokument. Der Manager hat den Dateinamen an STELLA weitergeleitet. Diese Anwendung stellt alle per Notification gemeldeten Dateien nun zur weiteren Bearbeitung, also beispielsweise den Import in eine Datenbank, im Dialog Dateiliste bearbeiten zur Verfügung.
Nach dieser allgemeinen Übersicht wollen wir uns der technischen Realisierung widmen. Dem üblichen Procedere folgend, wird die Kommunikation zwischen dem OLGA-Manager und der Anwendung, die Notification wünscht, über Nachrichten abgewickelt.
Die wichtigste ist sicher OLGA_REQUESTNOTIFICATION. Mit ihr teilt eine Anwendung dem Manager mit, daß sie künftig über gespeicherte Dateien auf dem laufenden gehalten werden möchte, und zwar unabhängig davon, ob für diese Datei Links existieren, oder nicht. Man kann hierbei bestimmte Typen anfordern (dann ist dem Manager eine Extension in Großbuchstaben, also zum Beispiel .IMG, zu übermitteln) oder aber das Speichern von allen Dateien.
Den Gegenpart hierzu übernimmt OLGA_RELEASENOTIFICATION, womit sich entsprechende Nachrichten abbestellen lassen. Diese werden durch OLGA_NOTIFY übermittelt. Der Empfang ist in jedem Fall durch das Schicken von OLGA_NOTIFIED an den Manager zu bestätigen. Mehr ist an Kommunikation zwischen der Ziel-Anwendung und dem OLGA-Manager nicht nötig.
Die Einleitung war zweifellos länger, als der Hauptteil. Dies liegt natürlich daran, daß Notification keine sehr aufwendige Angelegenheit ist. Ich hoffe, ich konnte aber verdeutlichen, warum dieses Konzept durchaus Sinn für bestimmte Anwendungen machen kann.
Dennoch vielleicht eine kleine Warnung: reine Server-Anwendungen werden von Notification sicher nicht profitieren. Deshalb sollten sie den Mechanismus auch nicht anfordern, denn warum sollten unnötig Nachrichten im System verschickt werden?
Aussichtsreiche Kandidaten sind hingegen Katalog-Programme, Anwendungen, die eine Versionsverwaltung realisieren, sowie vielleicht Shells, die unter Umständen geöffnete Fenster aktualisieren könnten.
Damit darf ich mich zunächst als Gastautor verabschieden. Um rauszufinden, wie es mit OLGA weitergeht, sollten Sie ganz einfach weiterhin fleißig die ATOS studieren. Viel Freude damit ...
Thomas Künneth