What’s the Fuss? SL is Already Interoperable

The story goes something like this: The online services CompuServe and Prodigy were walled gardens. For example, you couldn’t send an email from one to the other. Then the World Wide Web came along and it was interoperable and so CompuServe and Prodigy died. Second Life is a walled garden. SL needs to become interoperable or it will die.

Walled garden

It’s a nice story, but it’s wrong. For starters, CompuServe and Prodigy didn’t die; they just changed. For example, Prodigy Internet is now the largest Internet service provider in Mexico.

Moreover, SL is already interoperable, and getting more interoperable all the time. You don’t believe me?


For starters, you can send email from Second Life. This is done by putting a script in an object  using the LSL command  llEmail(). For example, you could make an object that emails you when it gets touched. Yes, there are limitations on message length and how often you can send emails. So? My point is that you can send email out to the wider Internet from inside SL.

SL objects can also receive email, using the llGetNextEmail() command and the email() event handler. In fact, some systems in SL use email to enable communication between distant SL objects (e.g. older networked vendors).

If someone sends you an IM when you’re not inworld, you can get the IM sent to your email. (To enable this, go to the top menu – Edit – Preferences – Communications tab, and check the box beside “Send IM to Email”.) Fun fact: If you reply to those emails (via email), the reply will show up as an IM reply back inside SL! Here’s a tip from the SL Knowledge Base:

“Tip: When replying to an IM by email, you should remove any quoted text from your reply. Instant messages have a maximum length of 1023 characters; if your message is longer than this limit, you receive an automated reply stating that your message was too long to be sent.”

Furthermore, when you take a Snapshot in SL, you can send it to a friend (or Snapzilla, which can forward it to Flickr) via email.  The email can include text of any sort; it need not have anything to do with the snapshot!

Once HTML-on-a-Prim is better, you’ll also be able to send and receive email via the Web (e.g. at Gmail or Yahoo! mail).


HTTP (HyperText Transfer Protocol) may look familiar… It’s the first four letters in website addresses like http://www.sltechworld.com

It’s a standard communication protocol and SL can use it to communicate with the rest of the Internet in a few ways. The most visible way is by using it to get a web page to show on the side of a prim (HTML-on-a-Prim). Currently, that’s one-way: you can see the web page but can’t send information back to it. Linden Lab plans to add that ability in the future.

(Actually, you can use the parcel media to send data out to the Web, by tacking the data on to the end of the website address, as in http://example.com/myscript.php?data=45.6|55.9|hippo — using llHTTPRequest is better though; see below.)

SL also allows you to see web pages inside the client on a window, with the option of opening them in your default external web browser. Those windows are opened via the LSL command llLoadURL (which takes the website address as one of its inputs), and can be interacted with just like a usual web browser (click links, fill forms, etc.).

SL profile windows can also show websites, on the second “Web” tab.

For scripters, the best way to use HTTP to talk to the rest of the ‘net is by using the llHTTPRequest() command and the http_response() event handler. That’s how to make vendors that you can manage from the Web, for example. It’s also how some traffic-measuring systems send sensor data to external databases.

Streaming Media and Music

Second Life can also play many kinds of media (e.g. still images, video or music) from out on the Internet. (By video, SL means anything that QuickTime can play.) That is, you don’t have to upload the media into SL first. You just specify the URLs in the World – About Land – Media tab (when you have permission). SL plays the media from wherever it’s hosted.


Second Life also lets scripts communicate with the wider Internet using a protocol called XML-RPC. I’m not going to go into too much detail other than to note that the capability exists. I get the impression that XML-RPC is considered dated compared to other protocols.

Standard File Types

Another aspect of interoperability is using standard file types, so that content can be uploaded to SL or downloaded from SL and used in other software. SL uses many standard file types:

  • Image upload: Targa, JPEG, BMP, or PNG files (max resolution of 1024 x 1024 pixels)
  • Textures can be downloaded as Targa files, if you have sufficient permissions (by opening the texture then going to the File menu)
  • Sound upload: WAV files in standard PCM format, 16-bit, 44.1 kHz, mono or stereo, ten seconds or less
  • Animation upload: BVH files (BioVision Hierarchy)

Some people complain that SL doesn’t let you upload standard 3D model formats (like OBJ or COLLADA), and therefore SL isn’t interoperable.  As listed above, SL is interoperable, in many ways. Just becaue SL doesn’t support your pet file type doesn’t mean it’s totally non-interoperable.

Yet Another Meaning for Interoperability

Interoperability has at least one other meaning. Some people want to be able to kill a dragon in Dragon Lands Online then take its head into Second Life to throw a celebration. This would require DLO and SL to agree on some protocols for managing things like identity and digital assets (inventory). This meaning of interoperability — the ability to move identity and assets between virtual worlds (or to manage them independently of any one virtual world) — has gotten a lot of attention lately.  Similar things are brewing on the Web. For an example, see the DataPortability Project.

Don’t Miss The Real Story

These days, when people talk about the work being done to change the underlying architecture of SL, they tend to emphasize that it will lead to greater interoperability. While that’s true, there’s a much more important story (in my opinion): the fact that the new architecture will allow SL to grow (or “to scale”) much better. That is, the new architecture will let more residents be inworld at the same time, and they’ll all get a higher-quality experience. Zero Linden has said that he’d like the new architecture to be able to support 50-100 million concurrent users (compared to around 60 thousand today).

More information about the new grid architecture is on the Architecture Working Group wiki. Note:  I’m not a member of the architecture working group; I’m just an interested observer.


SL is already quite interoperable with the rest of the Internet. It uses many standard protocols and file formats. While SL isn’t 100% interoperable, few things are! I’m impressed by the current level of interoperability, and encouraged by Linden Lab’s goal to make SL even more interoperable.

Is SL a walled garden or not? Let me know what you think in the comments.

Photo credits: Walled garden by monkeyatlarge on Flickr is licensed under a Creative Commons Attribution 2.0 License.

A friendly human.