What you're looking at above is a Second Life screenshot that changes everything. It's a new, open source[-based] version of the SL viewer, and though it's severely limited-- you can use the SL map, teleport, chat and IM, and check your friend/L$ status, and that's pretty much it-- it has one signature advantage.
This is Second Life from the Web.
Firefox and Safari to be exact, running a version of SL through Ajax. According to Katharine Berry, creator of the aptly-named AjaxLife, it also runs less well on Internet Explorer, Opera, and Wii Opera. Up to now, accessing SL requires a separate client download and a powerful graphics card-- two high hurdles for almost everyone on the Internet. A number of SL competitors have been targeting this very weakness, aiming to create a Web-based user-created world without such an awkward, time-consuming barrier to entry. Using protocols from libsecondlife, the open source SL project, Katharine has changed that assumption considerably. "If there’s enough interest," she concludes with winning modesty, "I’ll make a version that you can run on your own machine to connect to, once it’s further developed (e.g. starting IMs, profile viewing, possibly inventory management, etc.)"
Katharine, which should surprise no one, is a British teenager who built this partly out of "boredom, wanting to talk to people in" Teen Second Life. Nothing like disrupting the entire online world industry just for fun. Read about it on her blog.
Update, 4:15pm: Katharine speaks! The prodigy developer just e-mailed me an extensive interview about developing AjaxLife. (I'd have met her in-world, but, well, she's only 15, and still in Teen Second Life.)
After the break, read about how she built AjaxLife and where she'll take it from here.
Update 2, 7/13: As promised, Katharine has released AjaxLife's source under a revised BSD license.
AjaxLife: Where it goes from here
I intend to add more stuff, as I've said, such as starting IMs, search, profile viewing, texture viewing, texture uploading, possibly notecard editing, group chats, need to make it pick up offline IMs (which it doesn't - they'll be waiting until the next launch of the official client), etc. If it were to include building it would require you to be able to see what you were doing; this would at least partially defeat the point. It'd be nice, but is unlikely.
More important, in the near future, is fixing some crash bug (which isn't actually a crash bug so much as a stop-responding-to-any-network-input bug), and moving it onto another, more powerful server. The load currently being experienced was completely unplanned; it was planned as just a "I'm bored and want to talk to me friends in SL from school."
Open sourcing it under some nice open source license is on the todo list as well. I'm somewhat reluctant to do so, however - I don't really know C# very well (learnt it by making LibSL bots), so my code probably breaks all sorts of best practices.
How Katharine came to SL and created AjaxLife
I joined SL, rather dully, because Apple happened to have it as a "featured game" on the default Safari homepage. And it looked fun, so I signed up. This was the week after the Teen Grid entered public Beta, and there was no hint of it on the site. It's a good thing I didn't read the 18+ bit; otherwise I probably wouldn't be here now! (And no, I've never been on the main grid.)
I started with web development stuff when I was about nine (having learnt some dialect of BASIC when I was 8, unintentionally), and started on actually vaguely interesting stuff when I was 13. I actually learnt how to do the sort of thing involved with AjaxLife (e.g. a useful implementation of AJAX) while making it - that's my general approach to learning things.
How AjaxLife works (the full technical monty)
The connection to Second Life is handled by a C# program running under mono on my server, which uses libsecondlife to deal with SL connections. This is also running a webserver, which handles the web requests. This program actually hides behind apache2 using mod_proxy, which makes supporting secure connections much easier.
This is the cause behind the proxy errors you get when it's not working. The program is about C# is about 1,000 lines, and works by generating a new session whenever the login page is requested. If a login is made, the session gets a libsl SecondLife object, as well as my own Events object that handles all the libsl callbacks, processes them, and dumps useful responses into the message queue to be picked up later (usually meaning a split second later.)
If no requests are made for five minutes (which shouldn't happen if you've logged in, given a request is made every 30 seconds), the session is destroyed.
How AjaxLife’s Map works
This is a separate system entirely, and is somewhat messy. It calls from my own version of the Map API. This version splices together bother MG and TG regions - LL's data is used for the main grid and my own for the teen grid. Every day at Midnight (GMT/BST, depending on season), another libsl bot of mine logs in and downloads all the map images. This is used for my own map API (at http://services.katharineberry.co.uk/mapapi/). At the same time, another script downloads LL's map API, and saves a copy of it to my server (my server serves with gzip compression, theirs does not. Their 1MB download is 120KB from mine) at http://services.katharineberry.co.uk/mapapi/llmapapi.js.
It also processes it a bit - because LL's breaks any site that uses prototype or scriptaculous, it strips that out and saves this version at llmapapi-noprototype.js. It also takes the grid size constants from the top of the file and saves them to llmapapi-size.js. Finally, it takes the final bit of the file, which has all the sim data, and saves that at llmapapi-nocode.js. My multigrid map API uses data mashed up from the -size and -nocode files, as well as my own.
As a side note, it would be appreciated if LL were to provide a non-compressed version of this code for easier hacking around in. It is not obvious that the variable "$0h" controls where map images are pulled from.
AjaxLife implements the map by calling it from its alternate secure location with all the options thrown together at
https://secure.katharineberry.co.uk/mapapi/noprototype/multigrid/. It then abuses it in various ways to control the fields in ways apparently unthought of by LL.
But there you go. That's enough map ranting.