2-way messaging with Second Life

So I'm messing with the idea of a messaging hub for Second Life. The idea would be to create a web app that would accumulate messages bound for named objects in Second Life. These would queue up in a database, and be delivered in batches over some period that would not kill the sim in question.

So you'd have a table with stuff like this:

sl_bound_messages
----------------
id
destination (fk to id)
contents (right now, big varchar text)
source (source of message)
delivered_at (time of batch pick-up)
hub_pickup_id (fk to hub)
status (p = pending, b = batched, e = error, n = no object)
date_created (will be queue time)
date_updated

So an external application, fed by a GPS unit, could report the location of a RL object. This hub would accept the report, and hold it until it can push it through to Second Life. The hub could wait for polls from a 'repeater' in SL, which could be a prim running http requests on a timer. The 'repeater' would call up to the hub, get a batch of messages, and then distribute them around to target objects.

Objects in SL could also be hooked into the hub, in two ways:

• An object can be scripted to listen for, and register with, a hub. The object could report its location in the sim as it is pinged, as well as the unique id that is assigned to it. This gives some ability to track the location of objects within SL, and allows the hub to provide a handle to objects in the sim by relating a name with the SL-assigned unique id.
• The hub could know the objects it 'has', and route messages to the objects. The hub would request batches of messages on some period.

The hub could keep a registry that looks something like this:

sl_uids
-------
id
sl_uid
object_name
description
type (a = avatar, o = object, h = hub)
last_check_in
object_location_x
object_location_y
object_location_z
date_updated
date_created

So how to efficiantly distribute messages, and how many http requests and deliveries can be done without causing lag is a question, but I have some things in mind given these facilities. Much of LSL is undocumented, so there could also be better ways of doing this, but sure sounds like a fun experiment

The hub would keep a queue of messages like this:

sl_bound_messages
----------------
id
destination (fk to id)
contents
source (source of message)
delivered_at (time of batch pick-up)
hub_pickup_id (fk to hub)
status (p = pending, b = batched, e = error, n = no object)
date_created (will be queue time)
date_updated

Also, a simple event publishing mechanism seems useful, where SL objects publish an event, and RL things can be notified. Simply, a prim with an LSL script could shoot out an http request on some event in SL, this would go up to the hub, and the hub could allow registration of these events to interested parties outside. These events could note the object, object location, and any other relevant data, and the real world could react.

I've got RadRails fired up, and gonna start hacking.