Baba Sucks

Cory’s town hall went off pretty well, except for some repeater issues. Cory covered most of the major topics in his info-dump. Linden Lab is working on scaling, and it’s hard work(tm)

Here’s some of what Cory discussed, covering HTML on a prim, libsecondlife, open source, Mono, and the ever popular Havok. I’ve removed all those annoying line breaks in what was essentially a copy and paste job.

(full transcript)

HTML and Firefox . . . ah my two favorite topics of all time. We have an external contractor who has tons of experience working on it right now. Basically we’ve been trying to make sure that we can get Flash working correctly because so many of the interesting parts of the Web are moving to Flash-based players/plugins/etc. Getting the control inputs and updates to work correctly is a bear but they do seem to be making progress, which is very exciting. The order of operations will be to roll a full internal browser first, then supplement the parcel media types with URLs, and then move to full HTML on a prim. Note that HTML on a prim has several pieces, from being able to interpret straight HTML in order to build text, do layout, etc, all the way to having a face of a prim point at a web page. In terms of timeline, the next major Firefox roll out will be in Q1 – ie, more functionality in the existing pages that use it plus a floater that is a browser – followed by the parcel URL in Q2. HTML on a prim will be part of a larger rearchitecture of textures – we need to go to materials per face rather than texture per face – which several of the devs are itching to work on, but will realistically not start until Q2. Now, the Amazon web services guys (and others) have already been using HTML to build text and then leveraged libSL to upload textures and such, but we really want to make that easier.

Speaking of libSL, there were some questions about why Linden Lab supports libSL. These are excellent questions. First of all, we can’t stop someone from attempting to reverse engineer Second Life. We could drive them onto dark nets by aggressively shutting down public forums, club them with the DMCA by adding homeopathic quantities of encryption, and/or engage in an arms race by constantly changing our protocols. Does anyone really want us to spend time doing those things? You’ll notice again and again that when we talk about features, bug fixes, or scaling issues that we have with SL that we are limited by development resources. Developer time is precious and trying to chase the libSL folks around would be an infinite time sink. Nor does that take into account the positives. The libSL folks have reported literally hundreds of exploits to us rather take advantage of them. Yes, there are members of their community who have done dumb things but what community hasn’t? I would much rather have that army of talented developers spending most of their time trying to make SL better than either driving them away or being in constant conflict with them. If they break the terms of service we treat them like any other resident, but just because they tinker does not make them criminals.

As we’ve talked about, the long term goals for Second Life are to make it a more open platform. Part of that process is learning how projects like libSL can be beneficial to all of Second Life. We should be thrilled that we’ve built an interesting enough set of technologies and communities that people want to tinker and explore. In the long run, this is why we’ve talked about wanting to be able to Open Source eventually. My hope is that in 2007 we’ll be able to get there.

As long as we’re on libSL, one of our devs has used it pretty extensively in testing Mono. We’ve had several full up tests of Mono running on grids and things are looking very good. Because the Mono project is still dealing with some security issues and we’re finding memory leaks both in our changes to Mono and their code, we’re moving slowly and carefully. Novell/Ximian have been really helpful, so we’re making decent progress. There are some technical changes we still need to make in particular, we’ll need to compile Mono on the server side which requires a distributed compilation service to be running on the grid (yay, backbone!) but I expect that we will begin testing Mono on the main grid in Q1/Q2 2007. The process there will be to have places on the grid where you can bring scripts and recompile them into Mono for testing. That will let you report broken scripts to us. Since Mono tends to execute LSL about 600 times faster, I expect that there will be some interesting borkage around carefully timed scripts.

Babbage has talked about the implications of Mono extensively, but it’s important to remember that the sequence will be:

1. Start allowing compilation of LSL to Mono/CLI. Test existing scripts like crazy. (Q1/Q2)
2. Think about ways to include other languages (Q>2)

Regarding Havok, we are once again considering how to use a version of Havok with a version number greater than 1. Stand by for more info Q1/Q2. There were several questions around search. We’re starting a pretty major design phase about search to look at how to make it not suck(as much.) We can talk about that more if you want to, but basically I know that we can make both the new user and regular user experiences way better than they are today. Design work starting there in Q1.