GS_COMMAND: Aye, Sir.

Wenn GS_REQUEST und GS_REPLY zwischen den Applikationen ausgetauscht wurden, steht die GEMScript-Verbindung im Prinzip und es kann losgescripted werden. Dreh- und Angelpunkt der Kommunikation ist hier die Message GS_COMMAND (0x1352), deren Verständnis seitens der Applikationen mittels Eintragen von GSM_COMMAND in msgs in der GS_INFO-Struktur ja bereits bestätigt wurde.

Der Aufbau der GS_COMMAND-Message ist folgender:

msg[0] GS_COMMAND (0x1352 (4946))
msg[1] die ID des Versenders
msg[2] 0
msg[3]
    +  Pointer auf Kommandozeile
msg[4]
msg[5] 0
msg[6] 0
msg[7] Gemscript-ID

Diese Message enthält in ev_mgpbuff[3] und [4] grundsätzlich einen Zeiger auf eine Kommandozeile, deren Aufbau wir ja in Teil I schon kurz gezeigt hatten. Was tun wir nun, wenn wir eine solche Message erhalten?

Fangen wir doch erst einmal damit an, uns das Kommando und die dazugehörigen Parameter aus der Kommandozeile zu extrahieren. Dazu schreiben wir uns, wie sollte es auch anders sein, eine Funktion, die ungefähr so aussehen könnte (ich beschränke mich jetzt mal auf zwei Kommandos):

#define GS_OPEN   1
#define GS_CLOSE  2

PARLIST *extract(char *cmdline, int *command)
{
    char *param;
    PARLIST *first, *curr;

    /* Kommando aus der cmdline holen
     */
    if(stricmp(cmdline, "open")==0)
        *command=GS_OPEN;
    if(stricmp(cmdline, "close")==0)
        *command=GS_CLOSE;

    /* Ersten Parameter holen bzw. nachgucken, ob überhaupt einer drin ist
     */
    param = cmdline + strlen(cmdline) + 1;
    if(*param==0) return(0);

    /* Und jetzt alle Parameter bis zum doppelten Nullbyte extrahieren
     */
    curr = first;
    do
    {
        curr = malloc(sizeof(PARLIST));
        curr->param = malloc(strlen(param)+1);
        strcpy(curr->param, param);

        curr = curr->next;
        param = param + strlen(param) +1;
    } while(*param!=0);

    curr->next=NULL;

    return(first);
}

Für die Parameter verwende ich hier eine einfach verkettete Liste, die eine Struktur

typedef struct parlist
{
    char *param;
    struct parlist *next;
} PARLIST;

benutzt. Das erscheint mir als der einfachste Weg, auch mit wirklich beliebig vielen Parametern fertig zu werden.

Daß die einzelnen Bestandteile der Kommandozeile durch Nullzeichen getrennt sind, kommt uns hier natürlich sehr gelegen, da das Auflösen der Kommandozeile so einfach durch strcpy, strlen und stricmp (die Kommandos müssen ohne Unterscheidung von Groß- und Kleinschreibung differenziert werden) vorgenommen werden kann.

extract() wird also vom Messagehandler der GS_COMMAND empfangenden Applikation mit der Kommandozeile und einem Zeiger auf eine Integer-Variable aufgerufen und gibt einen Zeiger auf das erste Element einer verketteten Liste PARLIST zurück. In PARLIST->next steht jeweils ein Zeiger auf den nächsten Parameter, der am Ende der Liste NULL ist. Wenn der Rückgabewert von extract() direkt NULL ist, enthält das Kommando keine Parameter. Das aus der Kommandozeile extrahierte Kommando steht nach dem Aufruf in der übergebenen Variable command, und zwar in Form der oben definierten Konstanten.

Wenn die Kommandozeile derart aufgedröselt wurde und nicht mehr weiter benötigt wird, können wir GS_ACK (0x1353) an die Versenderapplikationen verschicken, die daraufhin den Speicher für die Kommandozeile wieder freigeben:

msg[0] GS_ACK (0x1353 (4947))
msg[1] ap_id
msg[2] 0
msg[3]
    +  exakt die Werte der empfangenen GS_COMMAND-Nachricht
msg[4]
msg[5]
    +  Ergebnis bzw. Fehlermeldung als ASCIIZZ-Text (s.u.) oder NULL
msg[6]
msg[7] 0: (GSACK_OK)      OK, Kommando wurde oder wird ausgeführt
       1: (GSACK_UNKNOWN) Kommando unbekannt
       2: (GSACK_ERROR)   Fehler (Kommando nicht ausgeführt)

In ev_mgpbuff[3] und [4] schicken wir also einfach einen Zeiger auf die empfangene Kommandozeile, bei Index 7 den entsprechenden Rückgabewert an die andere Applikation zurück.

Für die weitere Verarbeitung der Kommandos gibt es nun mehrere Möglichkeiten. Empfehlenswert ist auf jeden Fall die Implementation eines Dispatchers, der nach dem Aufrufen von extract() aufgerufen wird und entsprechende Aktionen vornimmt. Nehmen wir z.B. einmal ein Programm an, das mittels einer Funktion FileOpen(char *path) eine Datei öffnet. Dann könnte der Dispatcher folgendermaßen aussehen:

int gs_dispatch(int command, PARLIST *first)
{
    PARLIST *curr_par = first;

    switch(command)
    {
        case GS_OPEN:   do{
                            FileOpen(curr_par);
                            curr_par = curr_par->next;
                        } while(curr_par!=NULL)
                        break;
    }

    return(0);
}

So würde also anhand des Kommandos command und des ersten Elements der Parameterliste first die Funktion FileOpen nacheinander mit den übergebenen Dateipfaden aufgerufen.

Abschließend brauchen wir eigentlich nur noch die PARLIST wieder freizugeben:

void destroy_parlist(PARLIST *first)
{
    PARLIST *curr = first, *next;

    do{
        free(curr->command);
        next = curr->next;
        free(curr);
        curr = next;
    } while(curr!=NULL);
}

Und fertig ist die Interpretation des GEMScript-Open-Kommandos mit beliebiger Parameterzahl. Die hier gezeigten Funktionen sollten leicht erweiterbar sein und können als Gerüst für die Implementation in eigene Programme dienen.

Und jetzt wollen wir den Aufbau der weiteren Standard-GEMScript-Kommandos und eventuell auftretende Probleme erläutern.

In der nächsten Ausgabe schließlich werden wir uns ein wenig näher mit dem Feature der Aufnahmefähigkeit beschäftigen. Dahinter verbirgt sich die Möglichkeit, Scripte nicht durch manuelle Programmierung zu schreiben, sondern Aktionen innerhalb eines Programmes wie auf Band "aufzunehmen" und als GEMScript zu speichern, um sie später wieder abzurufen. Gerade für User, die keine Programmiererfahrung haben, erleichtert ein solches Feature den Umgang mit GEMScript erheblich. Wie die Aufnahmefähigkeit zu realisieren ist, lesen Sie in der nächsten ATOS.

Olaf Piesche