Scripting away on the LOracle...

I haven't blogged recently because my Second Life time has been taken up by this neat little hack I've been working on... I've tinkered with Linden Scripting Language (LSL) in the past, but this is the first significant undertaking I've, well, undertaken.

The fun part of what I'm doing is that it's a classic client/server thing. There's an LSL script that runs in-world, and it communicates with a backend application running on a server somewhere. I'm using the python language for the server because I like it, and using the TurboGears application framework because it's easy.

What does it do? Basically, this:

  1. Remembers things people say about other people and repeats those things when people wander over or when you ask it.
  2. Tells you what people you trust think about people nearby, or other people.

It also has an API that can be used by other scripts who might want to query, say, someone's reputation before letting them onto their land, etc.

One of the first things I wanted to tackle was inter-script communication, because I read that LSL scripts are severely limited in the amount of memory they have available. I wanted my script to be able to understand JSON output from my app, so I wrote a basic JSON parser and made it into a script which communicated via link_messages. This worked really well and was great fun until I decided to skip the whole JSON thing for my client and just go with extremely basic text output from my server. Oh well. But the good news is, and the whole point of the exercise is, that I now have a library I can drop in in case my scripts ever need to talk to servers that only speak JSON.

The second new problem to solve was multiple client concurrency issues. The little hack I'm writing will be much more fun if it's worn as an attachment, and therefore we have to deal with the fact that there will be lots of little clients running around trying to talk to the server at the same time. This isn't usually a problem, but in this case, my script is designed to take input from any nearby speaker, not just its owner. In other words, it listens to whatever is said within a particular channel, and tries to process it via the server. This means that if there are multiple scripts in the same vicinity, each one will talk to the server with identical messages, unless they know about each other.

Solving this problem conclusively is not trivial. I seem to recall learning something about this class of problem back in college in some computer science class. But the solution has evaded me. Luckily, I came up with a hack that mostly gets the job done, and it isn't super-critical that concurrency be avoided, since the server knows how to ignore duplicate requests. It's mainly a UI thing in the client. I've tested my solution solo with about 15 client scripts running simultaneously, and it works fine.

It's been a fun project so far, and I've been showing it to a few people, and so far so good. It's not for release yet, but I've got some documentation in progress here if you're interested.

My working title for this hack is LOracle, as in Linden Oracle. I've been told it's a terrible name. Suggestions?