LSL im Zusammenspiel mit anderen Sprachen

Das heutige Thema ist eher an fortgeschrittenere Programmierer bzw. Skripter gerichtet, allerdings sicherlich auch für Anfänger interessant, zeigt es doch eine der vielfältigen Möglichkeiten, die mit LSL realisierbar sind. Ich möchte einmal die Funktionsweise eines Chatprogramms, das die Mentoren der Pixel-Islands nutzen, darstellen, um aufzuzeigen, wie LSL mit anderen Skriptsprachen oder auch Programmen kommunizieren kann.

Auf dem Bild rechts kann man bereits ungefähr erahnen, worum es sich handelt. Ein webbasierter Chat, der es auch ermöglicht, User in SL mit einzubinden und sogar IM nach SL, zurück oder innerhalb der Webseite zu verschicken. Vor allem wenn es mal wieder Login-Probleme gibt oder man kein SL sondern nur einen Webbrowser zur Verfügung hat, wird der Nutzen dieses Programms klar.

Nun, wie funktioniert das Ganze?
Schauen wir uns dazu erst einmal das Webinterface an.

Das Webinterface – Daten senden

Für das Webinterface spielen mehrere Technologien eine Rolle. Im Wesentlichen Ajax und PHP und damit verbunden natürlich Javascript und XML sowie für das Design HTML und CSS. Für die Speicherung der Userdaten sowie des eigentlichen Chats und der IM´s habe ich mich für MySQL entschieden. Damit alles läuft muss natürlich beim Client Javascript aktiviert sein. Um das sicherzustellen ist die index.html nicht mehr als eine Javascriptweiche. Im Header befindet sich ein <meta>-Tag, welches nach 5 Sekuden auf eine Seite weiterleitet, die dazu auffordert, Javascript zu aktivieren. Zusätzlich dazu befindet sich im Body ein <noscript>-Bereich, der den gleichen Link anbietet, sollte die automatische Weiterleitung nicht funktionieren. Ist Javascript bereits aktiviert, wird mit dem location-Objekt in einem <script>-Bereich sofort zur Login-Seite gesprungen und man bekommt quasi nichts von dieser Weiche zu sehen. Die Loginseite dient zur Authentifizierung der Nutzerdaten, indem man sich mit Namen und Passwort einloggt. Jeder interne Bereich enthält ganz am Anfang einen kleinen Scriptblock (require) der für die Authentifizierung zuständig ist. Hierfür werden Name und Passwort in einer Session gespeichert und überprüft, ob beide in dieser Kombination in der Userdatenbank vorkommen. Falls nicht, wird eine Fehlerseite aufgerufen und der User bleibt draußen.

Den eigentlichen Kernbereich bekommt man nach dem Login zu sehen (Bild links), während im Hintergrund der User in der Datenbank als online markiert wird und eine entsprechende Meldung in den Chat geschrieben wird (das Gegenteil beim Logout). Für den Chat benötigt man 2 XMLHttpRequest-Objekte. Eines, das Usereingaben und Chat entgegennimmt und verarbeitet, während das andere parallel alle 3 Sekunden den Chat, IM´s und Onlineanzeige aktualisieren kann.
Sendet man nun eine Chatzeile, wird diese mittels dem XMLHttpRequest-Objekt (ich kürze im weiterem mit Ajax ab, auch wenn dies eigentlich die Gesamttechnologie beschreibt) an ein PHP-Skript geschickt, welches diese in die Chattabelle der Datenbank zusammen mit der aktuellen Zeit und dem Usernamen einträgt. (Danach werden alle User, die in Second-Life im Chat eingeloggt sind überprüft und ggf. mittels RPC der Chat an diese geschickt, dazu später mehr.)

IM´s funktionieren vom Prinzip her ähnlich. Man hat hier zusätzlich die Wahl an wen und ob man sie nur nach Second Life, nur auf der Webseite oder an beides verschicken will. Ist eine IM geschrieben, wird diese in die Usertabelle des schreibenden User als ausgehend eingetragen und falls “Offworld” oder “Beides” gewählt wurde in die Usertabelle des Empfängers. Wurde “Inworld” oder “Beides” gewählt wird diese an ein fest installiertes Objekt in SL mittels RPC geschickt, welche diese als “echte” IM an den Empfänger zustellt. Das gleiche Objekt, ist auch für die Useronline-Anzeige auf der Webseite zuständig. Klickt man diesen Button, wird ein bestimmter Befehl zusammen mit dem Namen des Anfordernden an das Objekt geschickt. Ein zweites Script (damit das erste weiterhin ununterbrochen IM´s empfangen kann) holt sich nun mittels llHTTPRequest bzw. dem http-response-Event zuerst alle eingetragenen Usernamen und deren UUID´s vom Server und speichert diese in einer Liste. Danach werden die UUID´s einzeln mittels llRequestAgentData bzw. dem Dataserver-Event auf Online-Status geprüft. Wenn nicht Online, wird der Name aus der angeforderten Namensliste gelöscht. Die verbleibende Liste (also alle, die Online sind) bzw. falls die Liste leer ist der String “Niemand online.” wird dann in die IM-Datenbank das anfordernden Users sozusagen als ausgehende IM wieder mit llHTTPRequest zurückgeschickt. Die Dauer hängt natürlich von der Anzahl der im Chat registrierten Nutzer ab. Bei uns etwa 3 Sekunden.

Daten empfangen

Kommen wir nun zum anderen XMLHttpRequest-Objekt, nämlich das, welches Daten empfängt. Dieses wird vom Client automatisch alle 3 Sekunden aufgerufen. Dabei prüft es, ob es neue Chatzeilen seit dem letztem Aufruf in der Chatdatenbank gibt, sowie neue IM´s in der Tabelle des Users. Darüber hinaus holt es die Namen aller User, die online sind (zuerst auf der Webseite, danach die, der in SL mittels HUD (dazu gleich) eingeloggten User, an deren Name noch ein (SL) gehängt wird). Diese Daten werden in sauberes XML verpackt und zurückgegeben. Da Javascript das DOM-Modell verarbeiten kann, ist eine Navigation durch diese Daten recht einfach. Der div-Container der Onlineanzeige wird aktualisiert. Falls neue IM´s oder Chat vorliegen, wird der Inhalt des Chat-div-Containers in einer Variablen gespeichert. Anschließend werden die neuen Zeilen einzeln CSS-Formatiert (Systemmeldungen grün, IM´s rot, Usernamen blau, Text schwarz) zu dieser Variablen addiert. Die fertige Variable wird an den Chat-div-Container als Inhalt zurückgegeben.

Die Verbindung zu SL

Wie läuft nun die Kommunikation nach SL bzw zurück? Wie bereits angedeutet mit XML-RPC bzw. Http-Request. IM´s nach SL werden an ein festinstalliertes Objekt in SL geschickt, so dass der User keine weiteren Hilfsmittel bzw. Attachments braucht um IM´s empfangen zu können. Für die restliche Kommunikation ist allerdings ein HUD notwendig.

Mit dem rechten grünen Button kann man IM´s zurückschicken. Klickt man diesen, holt sich das Script zunächst wieder die Namen aller im Chat registrierten Nutzer mit Http-Request an ein PHP Skript, das die Datenbank anspricht. Man kann dann per Menü den Zielnamen auswählen und in einen zufällig generierten Listenkanal (um es Spyern nicht ganz so leicht zu machen) die Nachricht eingeben. Diese wird dann wieder per Http-Request über ein PHP-Skript in die IM-Tabelle des Empfängers eingetragen. Btw bleiben IM´s so lange gespeichert, bis der User auf der Webseite einmal ein- und wieder ausgeloggt ist.

Der orangene Knopf ist für den Open-Chat zuständig. Klickt man diesen wird ein RPC-Kanal zum Empfang geöffnet und der Key des Kanals in der Userdatenbank gespeichert. Dies ist nötig, da sich dieser Key bei jedem Neurezzen oder Simwechsel ändert; daher muss auch ein Simwechsel mittels change-Event abgefangen und der Key aktualisiert werden. Anschließend wird man in der Userdatenbank als Inworld-Online gekennzeichnet und eine entsprechende Systemmeldung kreiert. User, die ihr HUD aktiv haben, werden auf der Webseite mit ihrem Namen und dem Zusatz (SL) angezeigt. Anschließend wird wieder ein zufälliger Listenkanal geöffnet und es kann losgehen. Beim Schließen des Chats, der umgekehrte Weg. Gibt man eine Chatzeile ein, wird diese einfach mittels Http-Request via PHP in die Chattabelle eingetragen.

Der vielleicht interessanteste Teil ist die bereits mehrmals angesprochene Datenübertragung von der Webseite nach Second Life mittels XML-RPC. Bei jeder neuen Chatzeile wird an alle online geschalteten HUD´s (die RPC-Keys hat man ja dann in der Datenbank) die Chatzeile geschickt. Für diese Art der Kommunikation findet man hier bzw. hier Beispiele. Hält man sich allerdings an diese vorgegebenen Beispiele, würde jede XML Message an jeden einzelnen User ca. 3 Sekunden in Anspruch nehmen. Man verzichtet also LSL-seitig auf die Antwort (wozu auch?!) und PHP-seitig auf das Empfangen von Daten. So gibt es kaum merkliche Zeitverzögerung, alle User empfangen fast gleichzeitig und sind sofort wieder empfangsbereit. Eine fehlende Rückbestätigung birgt zwar das Risiko, dass auch mal Daten verloren gehen können, dies ist allerdings höchst unwahrscheinlich und bei einer wenig sicherheitsrelevanten Anwendung tragbar.

Pfuuuuuuuuhhh, das war zugegebenermaßen ein Haufen Stoff und für Anfänger im Prinzip nur Fachlatein. Dennoch hoffe ich mit diesem Beispiel einmal verdeutlicht haben zu können, was mit LSL im Zusammenspiel mit anderen Sprachen für interessante Möglichkeiten entstehen.

Der nächste Artikel wird sich wieder an Anfänger richten, versprochen :-)

 

6 Kommentare zu “LSL im Zusammenspiel mit anderen Sprachen”

  1. Theresa sagt:

    Also wegen meiner gigantischen Kenntnisse habe ich es schon beim Querlesen kapiert. Und ich muss sagen: Meisterhaft!

  2. Bartholomew Kleiber sagt:

    Mehr davon, bitte!!!

  3. Shea sagt:

    Applaus! Sowas müssen die Lindens erstmal hinbekommen. (bekommen sie aber nicht)
    Isa is the best programiechen in town :)

  4. Joran sagt:

    Generell würde mich interessieren ob auf diese Weise auch eine Kommunikation zwischen den verschiedenen Grids möglich wäre und ob es das System auch mal zu erwerben geben wird

  5. Bartholomew Kleiber sagt:

    @Joran: wenn Du auf die OpenSim Grids anspielst – die haben von sich aus eine IRC Bridge, die allerdings etwas anders als das oben beschriebene funktioniert.

    Man kann in seiner OpenSim einen IRC channel angeben und aktivieren. Alles was in den public chat geschrieben wird, kommt dann in einem IRC channel an. Andersherum kann man in eben diesen IRC channel schreiben, und das kommt dann wiederum in der OpenSim an.

    Das sieht dann z.B. so aus:
    http://twitpic.com/g7tv

  6. Joran sagt:

    ja aber eine IRC-Bridge ist doch sehr unsicher finde ich

Kommentar posten

    Tags


Switch to our mobile site