2 Das Konzept im Überblick

Wie im Vorwort schon erwähnt, handelt es sich bei GEMScript um eine Kommunikation zwischen GEM-Programmen, bei der Kommandos verschickt werden.

Der eigentliche Austausch basiert auf normalen AES-Nachrichten.

Das zugrundeliegende Prinzip der Kommunikation dabei ist eigentlich recht einfach:

1.

Eine Applikation, die mit einer anderen kommunizieren möchte, meldet sich zunächst einmal bei dieser Applikation an ("Hallo! Hier bin ich und möchte mich gerne mit dir per GEMScript unterhalten."). Dazu gibt es die Nachrichten GS_REQUEST und GS_REPLY.

2.

Danach kann bereits die "Session" beginnen, d.h. man schickt sich munter Kommandos zu. Dazu gibt es die Nachrichten GS_COMMAND und GS_ACK. Die Applikationen unterhalten sich, und sagen gegenseitig, was zu tun ist. In den meisten Fällen läuft das ganze recht einseitig ab, d.h. eine Applikation kommandiert, was zu tun ist (normalerweise der Script-Interpreter) und die andere Applikation führt es aus. Natürlich sind aber auch andere "Gespräche" denkbar.

3.

Will sich eine Applikation nicht mehr unterhalten, meldet sie sich einfach wieder ab ("Tschüß dann!"). Dazu gibt es die Nachricht GS_QUIT.

Für Leute, denen das zu einfach ist, gibt es noch ein kleines Schmankerl, das man in seine GEMScript-fähigen Applikationen einbauen kann - aber nicht unbedingt muß: Die Aufnahme von Aktionen (Makros). Eine Applikation, die das unterstützt, nennt man "aufnahmefähig".

Dazu wird nun zwingend ein Script-Interpreter gebraucht, der noch dazu fähig sein muß, Kommandos aufzuzeichnen, um sie später wieder abspielen zu können. Er muß quasi selbständig Scripts erstellen, aufgrund der Informationen, die ihm eine Applikation liefert. Führt man ein solches entstandene Script zu einem späteren Zeitpunkt aus, so wiederholt die Applikation sinngemäß genau das, was sie bei der Aufnahme gemacht hat.

Hier der prinzipielle Ablauf einer Aufnahme:

1.

Der Benutzer aktiviert die Aufnahme in einer Applikation. Die Applikation sucht daraufhin den GEMScript-Interpreter (startet ihn gegebenenfalls nach) und initialisiert die GEMScript-Kommunikation in gewohnter Weise mit GS_REQUEST/GS_REPLY. Meist muß der Benutzer nun noch ein File auswählen, in der das aufzunehmende Script landen soll.

2.

Die Applikation gibt dem Interpreter bekannt, daß sie jetzt gerne aufnehmen möchte. Dazu existiert die Nachricht GS_OPENMACRO. Ist der Interpreter einverstanden, schickt er GS_MACRO zurück, als Zeichen, daß nun die Aufnahme beginnen kann.

3.

Die Applikation sendet nun alle Aktionen, die aufgenommen werden sollen, mit der Nachricht GS_WRITE an den Interpreter. Dieser erzeugt daraus das Script.

4.

Beendet der Benutzer die Aufnahme, so sagt die Applikation dies dem Interpreter mit der Nachricht GS_CLOSEMACRO. Fertig.

Hat man eine Applikation erst mal GEMScript-fähig gemacht, stellt im Grunde also auch die Aufnahmefähigkeit kein großes Problem mehr dar.

Um das ganze zu vervollständigen gibt es noch eine weitere kleine Variante der Aufnahme: Die applikationsübergreifende Aufnahme.

Dazu ist eine weitere spezielle Applikation nötig, die diese Aufnahme koordiniert: Der Aufnahme-Server. Der Desktop "jinnee" funktioniert beispielsweise als ein solcher Server. Auch diese applikationsübergreifende Aufnahme sei kurz erläutert:

1.

Der Benutzer aktviert die applikationsübergreifende Aufnahme im Aufnahme-Server. Wie bei einer normalen Aufnahme, sucht dieser Server den GEMScript-Interpreter und initialisiert die GEMScript-Kommunikation mit GS_REQUEST/GS_REPLY.

2.

Wie bei der normalen Aufnahme, beginnt der Server, eine Aufnahme beim Interpreter zu starten (GS_OPENMACRO). Der Interpreter antwortet mit GS_MACRO.

3.

Außerdem versucht der Aufnahme-Server GEMScript-Kontakt zu allen laufenden Applikationen aufzunehmen (GS_REQUEST/GS_REPLY). Bei Applikationen, bei denen dies geklappt hat, löst der Server quasi "von außen" eine Aufnahme mit der Nachricht GS_MACRO aus. Sind die Applikationen von außen aufnahmefähig, fangen sie jetzt an, munter ihre Kommandos per GS_WRITE an den Server zu schicken. (Für die Applikationen ist der Server in diesem Falle der Interpreter.)

4.

Der Server sammelt alle aufzunehmenden Kommandos aller laufenden Applikationen, kennzeichnet diese speziell (um sie später beim Abspielen des Scripts wieder zu erkennen), und schickt diese neuen Kommandos als "seine" aufzunehmenden Kommandos an den Interpreter weiter. Dieser zeichnet sie im Script auf.

4.

Beendet der Benutzer die Aufnahme, unterbricht der Server die Aufnahme bei allen Applikationen ebenfalls wieder "von außen". Ebenso beendet er seine eigene Aufnahme beim Interpreter. (Beides mit GS_CLOSEMACRO). Fertig.

5.

Spielt man das entstandene Script ab, so findet der Interpreter nur Kommandos, die für den Server bestimmt sind, und schickt diese dann auch an ihn. Der Server wiederum erkennt, daß es sich um Kommandos anderer Applikationen handelt, und leitet sie entsprechend einfach weiter. Hier sieht man den Vorteil, den der Server hat, wenn es sich um ein Desktop handelt (wie im Falle jinnee): Läuft eine Applikation beim Abspielen des Scripts nicht, kann er diese meist ohne großen Aufwand einfach nachstarten, sofern die Applikation im Desktop angemeldet ist.

Nach diesem Überblick der Möglichkeiten kann die konkrete Dokumentation des GEMScript-Protokolls beginnen.