Baba Sucks

I was fiddling with the libsecondlife sources earlier today and got sceneviwer all nice and workie workie. Check out this comparison shot of Second Life from both clients.

Yeah I know it’s Super teh hotness! The 3D engine is written using Microsoft XNA, which sadly means it’s not cross platform ;0 OH NOES!

But wait! Here is the good news,

Mono.Xna

Description

An open-source implementation of XNA using The Tao Framework for cross-platform rendering through OpenGL and Mono. The Mono.Xna discussion forum is available here.

Status
Mono.Xna is in early stages right now, but the end goal is to allow XNA projects to be compiled and run on platforms other then Windows, without having to change any code.

Mono.Xna, was initiated by libsecondlife’s very own “That guy who does stuff on the mono project,” and aims to make all your cross platform 3D rendering woes a thing of the past.

^{GhettoTags: CLI, XNA, Mono, .Net, sexy, open-standards, open-source, your-mom}

A lot of cool people were at Lang.NET 2006. The most notable of them to me were Miguel de Icaza and Jim Purbrick. Miguel is notable for being the founder of the Mono and GNOME projects. Jim Purbrick is everyone's favorite Mono hacker at Linden Lab. It appears that Second Life caught the eye of attendees at Lang.Net. After the symposium John Lam posted to his blog an entry titled Why Second Life is Important.

Jim Purbrick writes to the Second Life blog,

…Cory and I presented Second Life and our work integrating Mono at the start of day three. Cory’s introduction to SL did a great job of convincing people who had heard of Second Life that they should take a closer look. John Lam, who is doing really interesting work with RubyCLR is now looking in to running RubyConf as a mixed reality event in Second Life. John was also great fun to hang out with and did a great job as resident photo journalist.

I was initially concerned that the collection of hacks I presented for embedding Mono in SL might appall people, but the consensus seemed to be that they were neat hacks and they generated a lot of discussion about potential future enhancements to the CLR. A lot of discussion at the conference was about supporting dynamic languages like Ruby which, like Second Life, would benefit immensely from support for continuations in the CLI. Hopefully we’ll see them in the future.

The talk went down so well that Thottram Sriram asked me to repeat it on Friday for the CLR team at Microsoft, which was also well received and generated another collection of tips for integrating the CLR based on their recent experiences with the CLR integration with SQL server…

Miguel sums up Linden Lab's presentation this way,

Cory and Jim talked about Second Life, the current scripting system used in Second Life and their efforts to embed the Mono VM inside Second Life. The first part of the presentation was done by Cory and he presented an overview of Second Life and the audience was hooked on the virtual world that they have created. They had to stop answering social questions about Second Life so we move could into the actual technical details.

Jim, who is a blast, introduced the technical challenges that Second Life has on scripts. They need to be able to load and unload thousands of scripts in a continuously running process, and they also need to stop scripts at any point to either suspend them or to move to another computer.

Second Life maps computers to areas of land, so a computer is in charge of running all the simulations, physics and scripts for a given portion of virtual land. When a person crosses the boundaries the scripts have to migrate from one machine to the next machine.

Today the scripts running on Second Life are a bit slow, so they are looking at Mono and the CLI as a way of providing more speed to their users and hopefully allow developers to write in other languages other than their Linden Labs Scripting Language.

They have a compiler that translates their scripting language into CIL bytecodes, and the preliminary results give a performance increase between 50x and 150x faster execution with Mono.

The challenge is to stop and save a running script. This is something that is relatively easy done with their scripting language, but it becomes trickier with the CLI.

Their implementation instruments the generated CIL assembly to allow any script to suspend itself and resume execution on demand. This is a bit like continuations, the main difference is that the script does not control when it is suspended, the runtime does. The instrumentation basically checks on every back-branch and on every call site whether the script should stop (in Jim's words, "eventually, you run out of method, or you run out of stack") and if it must stop, it jumps to the end of the method where a little stub has been injected that saves the state in a helper class and returns.

A very clever idea. Hopefully the slides for the presentation will be posted soon.

Following my attorney's advise I have obtained a Second Life account.

Update: Catherine Omega blogs about  Miguel and Lang.Net here and Tao Takashi here. Tao's post harkens back to a blog post by Robert Scoble's On not getting Second Life. My own follow up to Scoble and his commenters was Don’t get it? You don’t have to… Yet. It's people like Miguel de Icaza and John Lam who need to "get" Second Life. 

Yes It's true what the title says. libsecondlife does indeed have a new website. Check it out at http://www.libsecondlife.org/.  The SL Protocol wiki has become the libsecondlife and Second Life protocol documentation wiki. I'm just gonna call it the libSL wiki. OH YEA! You can find it at http://www.libsecondlife.org/protocol/

I am responsible for the site layout, so if you see any funky display problems you can let me know. Please pardon the sparse content at the moment, we'll be updating the site quite a bit in the next week or so.

For those of you who have no clue what the hell I'm talking about, libsecondlife is open source reimplementation of the Second Life networking protocol. This means it's fully independent from the official client, and it can construct and interpret any packet the official client can.

libsecondlife is not a Second Life client, but it can be used to create a Second Life client. libsecondlife is a library of functions that help a programmer connect their program to Second Life.

libsecondlife originally used the Boost C++ libraries, but recent development has focused on the C# version. C# offers greater cross platform compatibility through the use of .Net and Mono. Though .Net is only available for Windows, we strive to maintain Mono support in the core library. This means that libsecondlife is compatible with almost any system that is supported by Mono.

If you're interested in helping out with the libsecondlife project, visit our project page hosted at Gna!  You can also find us on IRC in the channel #libsl on EFnet servers

This started as a comment in response to a blog post by Robert Scoble titled 'On not getting Second Life'

Some people think Second Life is a geek thing. A techie paradise with no real purpose beyond being a cool toy. The truth is, many many people don't get Second Life because it's still very much in development. I can't say that it will become the new Internet. I can say without a doubt it will not replace the flat web.

So, who is not getting Second Life?

The average person doesn't seem to get Second Life. Is it a game? It's got to be a game, just look at it. It's in 3D, and it has little people in it who you move around. Some people don't like games, so they dismiss it. The rest think, "Oh yeah, I like games," and then they look for the objective. When they find none, they decides it's a very bad game, and they dismiss it. The ones that get past that find something that does interest them. It's still kind-of like a game, but

Most geeks don't even get Second Life because they look at it in say the themselves, "Is this my concept of the metaverse? No, it's not there yet." and then they dismiss it. It's not there yet, but it is coming.

For most users or residents, as Linden Lab likes to call them, of Second Life it is a game; a socializing game where they get to buy the latest flash and show off to their friends. The fact is, most of what you will see in Second Life is the Myspace or AOLer crowd gone 3D. It's easy to buy some flashing particles and a trashy outfit and congregate somewhere.

Why should you pay attention to Second Life?

The more important stuff that goes on in Second Life is not quite so flashy. BlogHUD and similar products are the exception to that. Those are the end user applications of the evolving technology. The less flashy development is what is going on with the back-end at Linden Lab and with external projects like libsecondlife .

libsecondlife provides an open source client networking layer that mimics the official Second Life client, which provides third party applications access to in-world resources. Things in development include Instant Messenger applications for various platforms such as Palm and cellphones, account management tools to organize your inventory or transfer funds between accounts, and importing of models from blender using a customized format. Linden Lab has shown great support for the project, though they are unable to share the protocol with developers because Second Life is still closed source.

As for Linden Lab themselves, they are moving towards more consistent protocols, and implementing capabilities through a REST-like interface.

The current system relies on UDP templatized by a message system that changes constantly with each new release as well as XMLRPC. Each change to the message template requires grid downtime for the update. XMLRPC is currently being used for all agent region changes, instant messages, on-line notification, and other  miscellaneous services in Second Life. Linden Lab has questioned the scalability of this system, because the query result cannot be easily cached.

Phoenix Linden says on the Linden Lab Ops blog in his post Second Life IPC,

This lack of easy caching has a price. Today, 20% of the central database CPU load is agent online status queries.

The REST capabilities interface will allow system resources  to be delegated from the simulator to the client over HTTP as well as offer the inherent cachability of the protocol.

Donovan Linden explains the process  this way,

So, how can we apply capabilities to this system? Well, the viewer has a trusted connection to the sim, and the sim has a trusted connection to the data server. This is why in the old system, all the data had to be shuttled through the sim to the viewer, instead of directly from the data server to the viewer. We couldn't allow arbitrary viewers to request arbitrary data directly from the data server. We will use capabilities to delegate authority from the sim to the viewer. 

When a viewer connects to the sim, once the sim has determined that it trusts the viewer, the sim will grant a capability. This process is very simple — the sim simply goes to the capability proxy and says "I would like to allow someone to access a url on the data server". The capability proxy makes a new unguessable url, creates a mapping between this public url and the private url, and returns it to the sim.

It's not just REST. The Mono powered scripting engine has been in development for some time now. This will allow for Linden Scripting Language to compile to CIL which stands for Common Intermediate Language, and even the inclusion of Mono/.Net languages like C#.

What happens in Second Life, stays in Second Life.

Not likely!!! Second Life is busting out of this closed system virtual world mold, and heading for integration. With the development of web-services and  the Mozilla browser in Second Life, the users of Second Life will be spreading themselves onto the 2D web from within Second Life. Streaming makes sense. Second Life streams all 3D content and other assets on demand. Second Life has terabytes of content. More content than you ever want to put on your hard drive. At the moment it's all streamlined primitive objects, but bandwidth and processing power are constantly scaling up. Before long, it will make sense to stream raw vertices.  With updated graphics and a powerful programming language available, developers will be freed to create almost anything at all.

Beyond just adding features to Second Life, there is Linden Lab's vision of Second Life as just another way to access the Internet. Linden Lab envisions millions of Second Life servers in the future. They could never host them all themselves.  It's been said several times over the past several years that Second Life will at some point become open source. If they want to reach a million servers, I think open source will be a requirement. Developing and supporting a technology that is used by millions requires at least one of the following. Open source development, or a huge backer like Microsoft. Linden Lab is not Microsoft, and they don't have a business model that will allow them play on Microsoft's level.

To sum it up, Second Life has access to the 2D web from inside the client. In the near future Second Life will have a REST-like capability interface for webservices, and aplications developed Mono/.Net programming languages in world.  Linden Lab intends to open source the server and client at some point. 

Second Life is not a closed system, and at some point it's going to have an effect on how you view the Internet. In the future, Second Life may become just another interface to the wide open Internet.