Das ATOS-Magazin 2/98
ATOS Programmierpraxis
GEMScript (nicht nur) aus Programmierersicht

# Wie funktioniert das ganze?

Die Steuerung einer Applikation wird über Kommandos vorgenommen, die in normalen AES-Messages verschickt werden. Durch dieses Vorgehen ist es relativ einfach, GEMScript in jedes beliebige GEM-Programm zu implementieren. Zuerst einmal müssen GEMScript-fähige Applikationen natürlich feststellen, wer überhaupt als Kommunikationspartner in Frage kommt. Der Scriptinterpreter (z.B. Scripter von ASH) prüft dies bei den Applikationen, die über das momentan laufende Script angesprochen werden.

Zum Initialisieren der Kommunikation dienen die AES-Messages GS_REQUEST und GS_REPLY. Beim Senden von GS_REQUEST kann der Initiator dem angesprochenen Programm noch eine Datenstruktur übergeben, anhand derer dieses feststellen kann, wieviel der GS_REQUEST-Sender überhaupt von GEMScript versteht. Umgekehrt schickt der GS_REPLY-Sender eine ebensolche Infostruktur mit, damit auch der Initiator (in unserem Fall also der Scriptinterpreter) weiß, wie er überhaupt mit der Applikation reden soll.

Zum Versenden und Bestätigen von Kommandos existieren zwei feste AES-Messages, GS_COMMAND und GS_ACK (GEMScript Acknowledge). Auf ein Senden von GS_COMMAND, z.B. seitens des Scriptinterpreters, antwortet die angesprochene Applikation mit GS_ACK, was soviel heißt wie "Verstanden, GS_COMMAND ist angekommen." Beim Senden von GS_COMMAND wird ein Zeiger auf eine Kommandozeile mit übergeben. Diese hat einen definierten Aufbau:

> "Kommando\0Parameter1\0Parameter2\0\0"

Als erstes kommt also das Kommando, danach durch Nullbytes (\0) getrennt die Parameter. Durch diese Definition sind sowohl dem Kommando als auch den Parametern keine größen- oder anzahlmäßigen Beschränkungen auferlegt.

Standardisierung trotz Flexibilität