Every now and again, you have a need for some “Persistent Storage” in SL. Maybe you want to track your visitors, or keep track of their scores, points, and inventory in some quest game, or something. I’ve been working on a way to do that using Amazon Web Services and I’ll write some articles about that.
I would very much appreciate your interest, questions, and comments!
Options for Persistent Storage
There are probably many options for solving this problem. Here are the ones I’ve used:
Google App Engine
The New Citizens Inc security system stores its bans database using Google App Engine. For each officer action of warning, ejecting, banning, or unbanning a resident. it makes an entry in an App Engine dataset. The source code for how it does it is unfortunately lost to NCI, but some years back I did experiment with doing the same thing. You write a Python program that accesses the database, and talk to it via HTTP, the usual web access kind of thing.
The main drawbacks to this approach are that you need an App Engine account, and to write some Python or PHP or something. Not difficult if you know how.
MySQL / PHP etc
You can do the same sort of thing if you have a hosted web server somewhere. NCI has one as part of their forum software, and I’ve written a PHP front end to a MySQL database that can support the security database. I wrote that as a backup in case the App Engine one goes down, which it will the first time they try to bill the credit care of its late creator.
Drawbacks here are, again, that you need an account, hosting, and some PHP or similar code. This approach is likely to cost more than App Engine, which has a free tier that’s pretty generous.
SL Experience Database
The Experience feature in Second Life includes a simple key-value data store, so if you have an Experience key, you can use their data store to keep whatever you want. We use that in Lexicolo, my home, as part of our very extensive, fun, and difficult quest. Our database keeps track of your inventory, your quest money, how many times you’ve been stung by bees, and so on.
The drawbacks here include that you have to have an Experience key active wherever you want to access the data, which isn’t likely if you’re roaming the whole web. And you’re pretty much limited to one key per Group. In addition, you need to sort out your own data structure, it’s just a simple key-value setup. We have a fairly complex JSON structure as our data record, with fields for whatever we keep track of. You could use a comma-separated structure, some parsable thing, any tune of your own invention.
The good news is that it does’t cost any more than your existing premium membership.
Amazon Web Services
I wanted to learn about Amazon Web Services (AWS) for my RL purposes, and it seemed likely that there would be something one could do. I’ve begun to do that, and have a lot of it working, and that’s what I’ll be writing about here.
In a nutshell, I’ve set up an AWS API Gateway, connecting to their DynamoDB database, which is a key-value database, not unlike the App Engine one or SL’s own Experience one. Like Google, it has a very extensive free tier, and using the API Gateway, you don’t have to write any code at all. You do, however, get to write a lot of very weird JSON, and the configuration of API Gateway, DynamoDB, and all AWS’s security and identification stuff can get pretty frustrating.
We’ll talk about all that later, in subsequent articles. Welcome to my nightmare.