Konzept einer Entwicklungsumgebung

Lösungen ist, daß sie entweder nicht wirklich anwenderfreundlich sind (wie der in Tinmith integrierte NFS-Server) oder die Installation einer speziellen Softwarekomponente auf dem Entwicklungs- bzw. Debugging-Rechner erfordern, die natürlich auf die jeweilige Plattform portiert werden muß.

Im ersten Schritt stellt der Web-Browser eine TCP/IP-Verbindung zum Web-Server her, z.B.

einem „Apache“ (siehe Abbildung 44). Dazu wandelt er zunächst den symbolischen Rechnernamen („www.zgdv.de“) mit der Hilfe eines Nameservers in eine IP-Adresse (192.44.35.21) um. Außerdem benötigt er die Port-Nummer, unter der der Web-Server auf dem Rechner zu erreichen ist. Diese Port-Nummer kann Bestandteil der URL sein (nämlich hinter dem Rechnernamen, mit einem Doppelpunkt von diesem getrennt), oder es wird der Default-Port „80“ verwendet, wenn wie in unserem Fall keine Port-Nummer in der URL angegeben wird.

www.zgdv.de localhost

Web-Server Web-Browser

HTTP GET

Pfad: /avalon/index.html

Abbildung 45: 2. Schritt - Der Web-Browser sendet einen HTTP-GET-Befehl an den Web-Server

Nachdem der Verbindungsaufbau gelungen ist, beginnen Web-Browser und Web-Server über die TCP/IP-Verbindung miteinander zu kommunizieren. Das dabei verwendete Protokoll ist, wie oben bereits erwähnt, HTTP. HTTP besteht aus einfachen Text-Nachrichten. Zunächst sendet der Web-Browser einen „GET“-Befehl an den Web-Server, in dem er den Pfad (in unserem Beispiel „/avalon/index.html“) des gewünschten Dokuments angibt (siehe Abbildung 45). Die komplette HTTP-Nachricht sieht beim Firefox-Browser z.B. folgendermaßen aus:

HTTP Request

GET /avalon/index.html HTTP/1.1

Accept: text/xml,application/xml,application/xhtml+xml, text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7

Accept-Encoding: gzip,deflate

Accept-Language: de-de,de;q=0.8,en-us;q=0.5,en;q=0.3 Connection: keep-alive

Host: www.zgdv.de:80 Keep-Alive: 300

User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O;

de-DE; rv:1.7.5) Gecko/20041108 Firefox/1.0

Die erste Zeile der Nachricht besteht aus dem HTTP-Kommando („GET“), dem Pfad des gewünschten Dokuments („/avalon/index.html“), und der verwendeten HTTP-Version („HTTP/1.1“). Der Rest der Nachricht ist der sogenannte Message-Header, in dem der Browser u.a. spezifiziert, welche Dokumenttypen in welchen Sprachen er akzeptiert. Hinter dem Message-Header folgt der Message-Body, der im Falle des GET-Kommandos aber leer ist.

www.zgdv.de /usr/local/apache/htdocs/

avalon/index.html

Lokale Festplatte Web-Server

Abbildung 46: 3. Schritt - der Web-Server sucht das gewünschte Dokument auf der lokalen Festplatte

Als Reaktion auf das GET-Kommando versucht der Web-Server, das gewünschte Dokument

„/avalon/index.html“ auf der lokalen Festplatte zu finden. Dazu wird der Pfad des Dokumenten-Wurzelverzeichnisses (z.B. „/usr/local/apache/htdocs“) vor den Dokumentenpfad gesetzt und die Datei unter dem resultierenden Pfad („/usr/local/apache/htdocs/avalon/index.html“) gesucht (siehe Abbildung 46).

www.zgdv.de localhost

Web-Server Web-Browser

HTTP Reply

Dokument: /avalon/index.html

Abbildung 47: 4. Schritt: Der Server sendet eine HTTP-Reply an den Web-Browser

Im letzten Schritt sendet der Web-Server eine HTTP-Reply-Nachricht an den Web-Browser (siehe Abbildung 47). Falls das Dokument nicht gefunden wurde, wird eine Fehlermeldung zurückgeschickt, ansonsten das gewünschte Dokument. Die Reply-Nachricht sieht in unserem Beispiel folgendermaßen aus:

HTTP Reply

HTTP/1.1 200 OK

Date: Fri, 11 Mar 2005 16:39:28 GMT

Server: Apache/1.3.28 (Unix) mod_gzip/1.3.26.1a mod_ssl/2.8.15 OpenSSL/0.9.7b

Last-Modified: Fri, 02 Apr 2004 12:36:12 GMT ETag: "16deb-5aa-406d5e3c"

Accept-Ranges: bytes Content-Length: 1450 Content-Type: text/html

...

In der ersten Zeile der Reply-Nachricht befindet sich eine Statuszeile mit der verwendeten HTTP-Version („HTTP/1.1“) sowie einem Statuscode („200 OK“), der das Ergebnis des HTTP-GET-Kommandos in einer von der Browser-Software interpretierbaren Weise zurückliefert. Der Statuscode 200 bedeutet in diesem Fall, daß das Dokument gefunden und das Kommando erfolgreich ausgeführt werden konnte.

Direkt nach der Statuszeile folgt wie beim GET-Kommando der Message-Header. Er enthält unter anderem Informationen über die Größe des Dokuments in Bytes („Content-Length“) sowie über den MIME-Type des Dokuments („Content-Type“).

Direkt im Anschluß an den Header folgt der Message-Body mit dem Dokument selbst (oben nicht mit abgedruckt).

Nach Abschluß des Dokument-Downloads kann der Web-Browser weitere Kommandos an den Web-Server verschicken oder die TCP/IP-Verbindung abbrechen.

Betrachtet man diesen Ablauf etwas genauer, so fällt einem ein wichtiger Punkt auf: Der dritte Schritt kann auch anders implementiert werden. Nirgendwo ist festgelegt, daß der Web-Server ein bereits existierendes Dokument von der lokalen Festplatte zurückliefen muß.

Anstelle dessen kann das Dokument bei jedem Abruf auch „on-the-fly“ generiert werden, entweder vom Web-Server selber oder von anderen Software-Komponenten. Genau dies wird auch bereits von vielen Web-Sites so gehandhabt, z.B. durch den Einsatz von CGI-Skripten, PHP, Active Server Pages (ASP) oder JSP. Letztendlich kann man den Download eines

Dokuments durch einen Web-Browser auch so betrachten, daß der Web-Browser über das HTTP-GET-Kommando einen beliebigen Befehlsstring an den Web-Server sendet, den dieser auswertet und das Ergebnis in der HTTP-Reply-Nachricht zurückschickt. Es spricht also nichts dagegen, daß man einen Web-Server in ein Software-Paket einbaut und auf diese Weise die Software mit Hilfe eines einfachen Web-Browsers über das Netzwerk fernsteuert.

Ein Einwand an dieser Stelle könnte sein, daß ein Web-Server wie z.B. der Apache viel zu umfangreich ist, um in ein Softwarepaket eingebaut zu werden – insbesondere im Falle eines AR-Rahmensystems für mobile Systeme wie Mobiltelephone oder PDAs, wo Ressourcen wie z.B. Speicher knapp sind. Auf der anderen Seite war bereits in einem der ältesten mobilen AR-Systeme, MARS [94], ein Web-Server Bestandteil der Systemarchitektur. Tatsächlich sind normale, full-featured Web-Server wie der Apache für diesen Anwendungszweck viel zu mächtig. Es wird ja kein Web-Server benötigt, der tausende von gleichzeitigen Zugriffen effizient und unter allen Umständen fehlerfrei ausführt. Hier geht es nur darum, eine Schnittstelle zwischen AR-Rahmensystem und Web-Browser zu schaffen, die es einem Entwickler erlaubt, über ein zweites Gerät die auf dem mobilen Gerät laufende AR-Anwendung zu debuggen. Zu diesem Zweck genügt schon ein kleiner, einfacher Web-Server, der nur wenige Ressourcen verbraucht.

Einen solchen Web-Server zu programmieren ist einfach. Er muß einfach nur die an einem Port eingehenden TCP/IP-Verbindungen entgegennehmen. Vom eingehenden HTTP-Request braucht er im einfachsten Falle nur die erste Zeile parsen, die aus den drei Teilen Kommando („GET“), dem Pfad des gewünschten Dokuments sowie der verwendeten HTTP-Version („HTTP/1.1“) besteht. Von diesen drei Teilen ist nur der mittlere (der Pfad) interessant, der sich mit Leichtigkeit aus der ersten Zeile extrahieren läßt. Daraufhin führt der integrierte Web-Server die im Pfad kodierte Operation aus und liefert das Ergebnis in der HTTP-Reply-Nachricht an den Web-Browser zurück. Alle diese einfachen Operationen lassen sich mit geringem Aufwand implementieren. Wer selbst diesen Aufwand scheut, kann auch auf einfache, frei verfügbare Web-Server-Implementierungen zurückgreifen, wie z.B.

WebFS¹⁵.

Wie kann man nun über diese Schnittstelle ein User-Interface realisieren, das es erlaubt, eine AR-Anwendung zu entwickeln und zu debuggen? Einfache, von der Laufzeitumgebung generierte Textdokumente können zwar einen Einblick in den Status des laufenden Systems geben, aber wie kann man auf diese Weise neue Knoten erzeugen oder Verbindungen zwischen den Knoten?

Um diese Frage zu beantworten, muß man wissen, daß die vom Web-Browser dargestellten Textdokumente in einer speziellen Layout-Sprache codiert sind, nämlich der „HyperText Markup Language“ (HTML) [95]. Diese spezielle Programmiersprache für Hypertext-Dokumente kann nicht nur das Layout des Dokuments festlegen, sondern unterstützt auch das Erzeugen von Eingabemasken, in die man Daten eingeben kann. Diese Daten können dann vom Web-Browser an den Web-Server zurückgeschickt werden. Die Eingabemasken können praktisch alle Elemente enthalten, die man von modernen 2D-Oberflächen kennt: Buttons, Texteingabefelder, Options- und Checkboxen, Listen, Drop-Down-Listen etc.

In Form der HTML-Eingabemasken stehen alle Grundbausteine zur Verfügung, um eine vollwertige 2D-Oberfläche zur Bedienung des AR-Rahmensystems im Web-Browser aufzubauen. Das AR-Rahmensystem stellt über den integrierten Web-Server eine Startseite bereit. Von dieser Startseite aus kann der Entwickler über Hyperlinks andere Seiten erreichen, die Informationen über den Datenflußgraphen des Gerätemanagements oder den

15 http://linux.bytesex.org/misc/webfs.html

Szenengraphen des Rendering-Systems enthalten. Dabei kommt dem Web-Interface die Tatsache entgegen, das alle Elemente dieser Graphen ein reflektives Interface zur Verfügung stellen, d.h. man kann von einem Knoten z.B. erfahren, von welchem Typ er ist, welche Out- und Inslots er hat etc. Die so erzeugten Textdokumente enthalten aber nicht nur textuelle Informationen, sondern auch Eingabemasken, über die man das System modifizieren kann.

Diese Eingabemasken bestehen aus den üblichen 2D-Userinterface-Elementen. Wenn der Entwickler einen speziellen Button (vergleichbar mit dem „OK“-Button in Dialogfenstern) in einer Eingabemaske betätigt, werden alle in der Eingabemaske eingegebenen Informationen in einer URL kodiert vom Web-Browser an den Web-Server übertragen. Der Web-Server dekodiert die URL, führt die gewünschten Modifikationen durch, und liefert eine neue, aktualisierte HTML-Seite mit dem modifizierten Systemzustand an den Web-Browser zurück.

Neben einfachen Modifikationen erlaubt es HTML auch, Daten vom Web-Server herunterzuladen oder auf den Server hochzuladen. Dies wird dazu genutzt, die Konfiguration des Systems in Konfigurationsdateien zu speichern oder aus Konfigurationsdateien zu laden.

Zu diesem Zweck gibt es wie von herkömmlichen 2D-Oberflächen gewohnt spezielle Buttons zum Laden und Speichern. Klickt man auf einen dieser Buttons, so öffnet der Browser einen Datei-Dialog, in dem man den gewünschten Dateinamen beim Speichern eingeben bzw. die gewünschte Datei beim Laden auswählen kann. Die Übertragung der Dateien vom mobilen AR-System auf den Entwicklungsrechner und umgekehrt erfolgt dabei völlig transparent für den Anwender.

Abbildung 48: Screenshots des Webinterface

Abbildung 48 zeigt einige Screenshots des Web-Interface. Links oben sieht man alle gerade gestarteten Knoten. Darüber hinaus werden Status-Informationen angezeigt – z.B. konnte in diesem Fall der Knoten zum Grabben von Videobildern nicht gestartet werden. Auf dieser Webseite können Knoten neu hinzugefügt, gelöscht oder neu gestartet werden. Wenn man einen neuen Knoten erzeugen möchte, klickt man auf den Namen, und die Seite rechts oben wird dargestellt. Der Anwender wählt aus der Liste der verfügbaren Knoten den gewünschten aus. Auf der folgenden Seite (links unten) kann er dann Parameter spezifizieren. Schließlich können Outslots und Inslots des neuen Knotens über Routes mit anderen Knoten verbunden werden (rechts unten).