WAP BOT

Tejeshwar Sangameswaran

Arpita Barua

* Wickedly Awesome PHP Bot

Abstract

Problem: The Second Life scripting language, LSL (Linden Scripting Language) has serious limitations. This limited capability and low fidelity of LSL makes complex tasks onerous or nearly impossible.

Goal:

  1. The goal of this project is to build an asynchronous data transfer interface between Second Life and a HTTP server. This framework would allow data to be not only fetched from a server, but also seamlessly push data directly into Second Life. This framework would allow the backend to be in any language; be it Java, PHP, Ruby, Python, etc.
  1. The secondary goal of our project is to built on top of that framework, an autonomous bot which resides on a HTTP server outside Second Life which can perform tasks which were before not possible inside Second Life (mainly because of the limitations of the Linden Scripting Language. The limited capability and fidelity of LSL makes complex tasks onerous or nearly impossible.) .

Individual Objective:

Tejeshwar: My task was the create the the interface layer between Second Life and the webserver. To create the server and the plugin framework. My task was also to create the server front end interface which provides information about the connected client.

Arpita: To finalize the plugin architecture. Design plugins for use with the server. Fine tuning and testing the bot. Improve server frontend to display more information about the client.

Result: All the project details described in the abstract were successfully achieved over the course of the semester.

Implementation and Architecture

We have accomplished asynchronous data transfer by using two different protocols to send and receive data. To send/fetch data from the client to the server we use RESTful methods. To push data into Second Life client from outside we use XML-RPCs. This eliminating handshakes, and thus allows asynchronous data transfer.

This in fact produces a problem of keeping track of messages passed between the server and the client. So, we have created a session management system in PHP which uses a MySQL backend to store and manage client sessions.

A real life example where this can be used is for example, if there is weather change; the server will capture the change and immediately push the new weather data into the mirror world and changes would take place immediately inside Second Life.


Components

Server

The server is coded in PHP and uses MySQL for its storage backend. The server opens up ports and waits for an incoming connection. As of now, the server is programmed to accept and work with only one client at a time.

As soon as the user connects, session variables are created to track data flow. The server acts a bridge between the Second Life wap-bot client and services available on the internet.

The server first and foremost empower users to get various (real-time) data with language-based instructions. The server enables on-demand data through mashups and extend and enhances the functionality of Second Life.

The server reduces several complicated and repetitive tasks easy through intuitive user-centric commands. The server acts like a kiosk.

Client

The main function of the client is to open up two different channels for xml-rpc and http requests. Once the channels are opened and successfully connected to the server, the user can type in messages to the wap-bot; which processes the information on the server side and replies to the user with the desired results.

All the processing is seamless and completely done in the background, so the user has a pleasant non obtrusive experience.

Server Plugins

The server plugins are attached to the server and easily expand the horizons of the server.

These are little modules that act as interfaces to information on the web. They are mashups which fetch and clean information for client.

Current developed plugins:

News: Fetches the headlines from current top stories. Can fetch separate stories for Technology, Health, Entertainment and Business news.

Syntax: news <headlines|health|entertainment|business>

Weather: Fetches weather for any specified city (or zip code) in both Celsius and Fahrenheit.

Syntax: weather <city>

Syntax: weather Fayetteville,AR

Calculate: Processes and solves any algebraic questions.

Syntax: calculate 55-44*32/2

Question: An 8ball implementation for an illusive AI.

Syntax: question <any question!>

Syntax: question Will I ever find true love?

Dictionary: Fetches definitions of words

Syntax: dictionary <any word>

Syntax: dictionary complicated

Roll: Rolls a dice, and tells the value on face of dice.

Syntax: roll dice

Plugin Architecture

  • Each plugin followed a standardized architecture.
  • They all built and have a similar set of function which describe it.
  • Its got functions that return the syntax, what the function does and plug in definition.
  • The plugin has a standardized process() function which is the first function which is called when the plugin in initiated (Analogous to a constructor)
  • When the server is initialized, it scans all the plugins, builds a plugin database and generates a command sensitivity list.
  • When ever the server encounters the matched keyword, it imitates the plugin process.
  • The server has a unified command set, so it interface with all plugins in a similar fashion
  • As of now, the plugin architecture is only on paper. It is yet to be implemented.

Sample Plugin:

weather_plugin.php

//plugin for retrieving weather information

include “pxweather.class.php” //3rd party api for parsing weather from weather.com

function initialize()

{

$arr = array('description'=>'Returns the weather',

'parameters'=>'Zip code',

'trigger'=>'weather',//keyword

'process'=>'weather',//keyword

'params'=>'varchar', //parameter datatype

'return'=>'varchar');//return datatype

return $arr; //for registering with server.

}

function process($param)

{

return getWeather($param);

}

//after this, this code is custom code for individual plugins.

function getWeather($zip)

{

$w = new Weather($zip);

$w->load();

return $w->getCurrent("temp.string"); //uses the PxWeather API to pull weather data.

}

Results

  1. All the described components were successfully implemented. Except for the plugin architecture.
  2. When the user enters within the proximity of the wap-bot, he is greeted and told to touch to object to initiate a connection.
  3. Once the channel is established, the user can connect to the server to establish a new session.

The syntax is connect <channel-key>

  1. Once the connection is established,

Once the user is in the proximity of the chatbox

He can use the chat box to interact with the wap-bot

  1. To disconnect from the server, the user simply touches the bot again

The user can also disconnect by using disconnect command.

Screen Shots

Touch the wap-bot, it gives you instructions to connect to it.


Connect using the connect keyword.


Once connected, you can interact with the bot.


Disconnect from the bot by just touching the object again.


Server interface shows client session information and illustrates the push data feature. (


Installation Instructions

  • In the included source code package, there is a 'Client' and 'Server'.
  • The client has two lsl scripts; the xmlrpc and httpreq, each setup two individual communication layers. They should be put into the same object.
  • The server has several files and dependencies. They all need to be placed with the folder structure preserved into the webserver.
  • The lsl client script 'httpreq' has a reference to the httpreq.php file on server, this needs to modified and pointed to the right url.
  • The cache folder and pretty much all the files on the server should have rwxrwxrwx

Conclusions and Thoughts

  • As you can see, the bot is very intuitive and greatly improves the user experience.
  • This framework can be easily reused for several different scenarios

Testing

  • The testing was mainly Ad-hoc based.
  • Unit Testing was done on the server side php functions.

Future Developments

A lot of advancements can be made to this framework to take this to the next level.

Immediate Future:

  • Implement the plug in framework.
  • Implement a chat interface between a website and Second Life: That way people on a website can directly talk to the player
  • Multithreaded server to accept several client connections

Future:

  • Modify Second Life environment based on data pumped into it making the it more closer to reality.
  • Build interfaces to write and import plugins in any language. For Examples: plugins written in Ruby and Java can be directly imported and used for processing. The tremendous amounts of open source software on the internet right now will effective increase the power and intuitiveness of Second Life exponentially.
  • Terminal Based Services: Since we have an framework built, we can build a client (similar to telnet) from inside Second Life to control a unix machine.

Distant Future:

  • Implement a full featured AI: Create a plugin that will be a full feature AI that will be based on ALICE. A bot that can talk back , respond and maintain a conversation with a user.

Bibliography

3rd Party API:

  1. pxWeather - Jonathan Abbett
  2. RSS_PHP – rssphp.net

Special Thanks:

  1. Dr.Craig Thompson – Teaching us about various software design paradigms and helping us refine our knowledge about software implementation.
  2. Keith Perkins – Valuable information about communication protocols within Second Life.

References: