SL/RL Interfaces — An Overview

There are three main interfaces that can bridge the gap between SecondLife and real life:

* e-mail – E-mail is the simplest of Second Life’s external interfaces and the one that can be used without an external server. On the downside, it also has the greatest lag and highest latency. Outbound the Lindens add 20 seconds of script lag to each call, inbound there’s no scripted lag but your messages are subject to normal E-mail delays. E-mail is designed to be slow but reliable, for example, the spec requires that clients retry failed messages and suggests a 30 minute retry interval. I’m sure you’ve seen much delays up even to several days.

* xmlrpc – xmlrpc is the only option that allows an external program to trigger an in-world event, in fact xmlrpc can only be triggered externally triggered though the script can send data out in a reply. Xmlrpc is low lag and low latency, the Lindens add 5 seconds of script lag and only when your script sends a reply. Sending a reply is optional from the standpoint of lsl, but not replying will likely raise an error in your external code. Xmlrpc communication is based on channels which are assigned by Second Life’s servers. Any program using xmlrpc must include a mechanism to get the channel identifier out of SL. The other two SL/RL interfaces are prime candidates though you could ask users to copy and paste. You should also make provisions to open a new channel when the old one idles out, the scripted object rerezzes or changes region, or the channel is closed by a grid reset. This is rare, but something you need to plan for.

* http request – while xmlrpc uses http internally you’re not supposed to think about that. If you wanted to think about it you would use http request. Http request effectively turns Second Life into a web browser. Http has no lag and low latency, the Lindens limit it to 100 requests per 100 seconds, you’ll have to add your own lag if needed to stay within that limit. You can use three of the http methods; GET, POST, and PUT. GET and POST are commonly used in web sites, with a little bit of effort you can interface them to any web framework you’re familiar with, either to retrieve data or send it to a form. You’ll need to format your data and run it through llEscapeURL yourself, but your framework will handle it from there just fine. PUT is a little less common in web applications and may turn up somewhere odd in your framework, but it can be used to send unformatted data very nicely. All http requests are initiated from within Second Life, but they can retrieve up to 2k from your web service. With the low lag you could easily poll to allow an external service to trigger events in SL.

I’ll write more about each of these in later entries or take questions by comment or e-mail.