Interfacing Second Life®

and the World-Wide Web

Gwyneth Llewelyn
gwyneth.llewelyn@betatechnologies.info
Second Life in 5
minutes
3D virtual world where all content is created by its
users, within a contiguous landscape

Content is programmable

Used in education — from the virtual classroom to

novel ways of teaching

Simulations, creating interactive 3D

representations of data

Almost a decade old (mature technology)

 Programming limitations
Unique event-driven language: Linden Scripting
Language (few programmers!)

Data and code are limited to only 64 KBytes (!)

Each script runs on a tiny Mono VM, but

performance is dependent on region

Artificial delays and limits imposed by Linden Lab

— workarounds require expertise

Virtual Worlds with user-generated content like Second Life® or OpenSimulator provide a fascina=ng new tool for educa=on and simula=on, allowing educators and researchers to explore with a rela=vely simple interface the possibili=es of immersing students (and visitors) in a 3D world with full interac=vity. While
all content and programming can be done from within the free Second Life Viewer applica=on, programming complex applica=ons inside Second Life is oGen challenging, as the built-in programming language has several serious constraints and limita=ons.
A solu=on is to use the func=onality to allow outbound HTTP connec=ons to external servers providing web services, or allow web servers to make inbound HTTP connec=ons to directly manipulate objects inside the virtual world, and leave all the complexi=es of programming and persistent data storage on the
external server. The 3D virtual world thus acts as an “interface” to a more complex applica=on, similar to the role of JavaScript-enabled pages to do client-side rendering, but retrieving data and the complex logic from the web server itself.
This session will show some simple techniques to illustrate how this can be accomplished with a few programming demonstra=ons, live from within the virtual world.
To fully appreciate this session, a reasonable programming experience with any programming language is required; examples will be shown in PHP and Second Life’s proprietary language, Linden Script Language, which is vaguely inspired on JavaScript.
Why the need to use
external servers?
Address memory and performance limitations

Interface with web services

Persistent storage

Use Second Life as a front-end to create

interactive 3D model for abstract data
 Typical examples

NOAA — Weather being displayed over a map. Visitors can see things move!
Election results — as they come in, selected parts of the map show results
Location of ships and submarines: data on servers is polled and presented visually in 3D
The basics
Linden Scripting Language is event driven

Outbound communication uses llHTTPRequest

(2048 bytes only), which can return a status (text)

For inbound communication, object has to register

itself with llRequestURL() — this will give a
valid URL for contacting the object via a callback

Each external contact (also up to 2048 bytes)

triggers an event in the object
Visually... outbound
LSL Script Web server

Function call

llHTTPRequest() to call
external server HTTP
GET/
POST Validate request, do
what is requested, and
send back status
-8
TF
nU
ly i
rep
http_reponse triggered
with status
Visually... inbound
Second Life LSL Script Web server
Central Servers
Register external URL

llRequestURL()
quest
Randomly generate valid URL re
URL and return it to
running script Gen
erated
URL http_request triggered
with method ==
URL_REQUEST_GRAN
TED

Store URL remotely

Register Object
llHTTPRequest() to call
HTTP G
external server with the ET/PO • Validate request (check
ST
inbound URL for later Genera
ted UR object UUID)
reference L
• Store generated URL for
-8 future use
TF
nU • Generate response
p ly i
http_reponse triggered re
with status; if storage
fails, try llRequestURL()
again...
Make inbound call

Select pre-generated
T URL for the object and
OS
T/P make a HTTP GET/
• http_request GE est POST
triggered with method T TP q u
H re
== POST or GET with
• Process request HTT
• Trigger response to P sta
web server with and tus cod
text e
llHTTPResponse()
Process result
To recap...
Sending data out of Second Life is easy: make a
request from the script to the external web server,
get a reply. So long as all is under 2 KB it works!

Contacting an in-world object requires registration

of a valid URL to contact that object. This means
that this valid URL has to be stored on an external
database first. The object acts as a tiny web
server providing very simple web services.
Limitations
The 2 KByte limit for requests and replies means that typical
message formats will not be appropriate (e.g. XML consumes
too much spaces)

Even more compact formats (e.g. JSON) are not natively

supported and require parsing (hard to do, consumes CPU)

LSL code has to deal with timeouts and hitting limits (anti-
spam measures to deal with too many requests)

Web-based code has to keep track of active/inactive URLs

for objects (because they can be deleted, change owner, etc)

So: all the communication has to be very simple

Let’s see some
examples
Talk like a pirate translator!

Very simple to do:

Capture the text from an avatar

Call external web service with llHTTPRequest

The return is XML, which requires some parsing

Extract the relevant text and echo it to the chat

Capturing information
on avatars
This could be used to set up an external
authentication system for a virtual classroom

Avatar touches on a door, which captures as much

data as possible, and sends it to an
“autenthication server”

If the avatar is allowed to enter, a reply is sent to

the door, which will then open

The transaction gets logged with timestamps

Modifying in-world
objects
Start by registering an object with our external
server

Provide a Web-based form to change some

parameters (we’ll just select a colour)

Notify internal object to change the colour via an

inbound call
More seriously:
registration with a site
Imagine you have a website just for Second Life
users. You wish to make sure that they use their
avatar name to register

Deploy an object which gets touched by the avatar

Avatar name is sent to the website; new user is

registered; password is sent back via (private)
message

Website also controls access and active objects

WordPress solution
Available from the WordPress Plugin Directory:
http://wordpress.org/extend/plugins/sl-user-
create/

Adds some extra security (cryptographic signing

on messages, limiting avatars or regions, etc.)

Tracks down all valid registration objects and

allows them to be reset/deleted

Allows users to change password

THANK YOU :-) QUESTIONS ARE WELCOME!
MY CONTACT: GWYNETH.LLEWELYN@BETATECHNOLOGIES.INFO