OpenSim unfinished symphony

Odd thing this; falling out of OpenSim development I feel like I imagine HAL did, parts of my self falling off and in the end I will probably do the programmer equivalent of droning "daaaisssyyy, daaaaaaiiisss..." and come to a grinding halt.

Before that actually happens, I'll just make sure to squeeze out this blog, listing the projects (aka 'really good and low hanging fruit kind of ideas') I wanted to do with OpenSim, but never got a chance to. If only for posterity. Here goes:

Identifying assets with URL, not GUID

The main idea would be to implement a model where the viewer and region communicated guids as asset id's, but that the regions communicated urls as asset identifiers to the back ends. This would lead to general awesomeness, as assets could truly be served by simple web servers. The region would then simply serve as an asset streamed redistribution cache, fetching data in arbitrary format and converting them locally to the format best suited for the given client. Of course, in the case of the LL stack, because asset data can reference other assets, you would have to substitute guids to urls and back in the asset data: the region would thus have to have a system to keep track of guid<->url mapping, but it is my firm belief that this is doable.

Status: I did start on this in trunk, but stopped; now it's been removed, but I believe I proved the guid substitution in asset data approach is doable.

Avatar Appearance defined by URL, not GUID

A companion to the above, the avatar appearance would be defined as a http endpoint; an xml file outlining the appearance pointing to assets by urls instead of a guids. The content could then either be assembled procedural, thru a database, or as a simple published xml file. If this would then be expanded to an "aar" (avatar archive) file format that encapsulates all the assets involved, this would take avatar portability home.

Status: Pure dreamland, but probably not that hard given the appearance is already fetched over http with guids, and OpenSim already have oars and iars.

Virtual Inventory Nodes

Each inventory node would be identified with an url, not a guid; this would lead to being able to distribute a users inventory over several services - allowing for services to update inventory nodes in real time, for example after a service upgrade of some inventory asset, interacting with a web page or changing to premium services. Think of the inventory a bit like 3d web 'favorites' links to content that still can change.

Status: Pure dreamland, and the feature could get pretty messy real fast. Still, it's probably the way to go. Arguably not that hard either given that inventory is communicated as xml over http in OpenSim today.

Unified UI Toolbox

The main idea would be to implement a shell executable that loads Mono.Addins for functionality separated from user interface, where the latter can be implemented for any environment (winforms, silverlight, ajax, gtk, you name it) whilst sharing the functionality (intelligent ini configuration, connectivity troubleshooter, region launching and monitoring, console command<->gui mapping, log file config and analysis, various launcher url schemes, database management et c) - this model would help developers cooperate on shared functionality and environment-specific UI separately.

Status: Proof of concept lying around on my harddrive, just editing a few ini settings in a WinForm gui. It works, and it's cool as heck.

Tribal One Viewports

In Tribal One, we had a 'viewport', which was a scene object defining a cube, in which content was governed by a http endpoint. In OpenSim, one could do a first implementation by implementing a non-backed up scene object that would "load xml" or "load oar" its content, rotated and displaced with the 'viewport'. The viewport also 'snapped' to other surfaces which let you for example define that a picture always hung on a vertical surface, or that a lamp always was aligned standing on the horizontal surface below it. Pure awesomeness taking building from generic objects so much easier. The idea was that content in a region would be 'assembled' from a great number of web sources, most of them probably programatically generated, procedurally or from databases, and other just simple static xml files.

Status: As with all Tribal One code, based on ~r2000 code, so a total mess to bring up to date.

On-demand regions

Basically, it would not be that hard to have OpenSim turn the solid-state running-region paradigm around, and allowing for on-demand regions that were started and loaded from database when somebody tried to teleport to them, and that closed down when nobody was around in them. This would mean the cpu capacity is not connected to land mass but to land use. Combined with the viewports, we're starting to look at something truly like a modern web page, where a region is started and generated in a response to a user need; you and I might be in very similar regions, but mine is subtly different because I wanted something subtly different.

Status: We did this in Tribal One, but all regions were started and served in one single instance, so didn't scale. Still, the result was amazing. In PIM, we had a 'pool' of region processes that were re-configured (re-loaded) as people wanted access to different 'class rooms'.

Binary de-duplication and scavenging

The idea is to split the asset table as so to extract the actual binary data out of it and into a separate table, with a foreign key. This way, you could make sure to do a SHA-256 hash on all new binary data and normalize the tables by making multiple assets point to the same binary data row and removing the duplicate. The process that computes SHA-256 and normalizes the asset table could run as a separate tool, or as a ROBUST service. On frequent archive (re-)loading, you would still have massive duplication of data rows, but at least the binary storage wouldn't swell just as fast.

Status: There's already a sha field in the asset database, this approach has been discussed back and forth, but nothing general has yet surfaced.

Epilogue: If anybody thinks any of this is a good idea, and want to know more of the thoughts behind it, I'd be more than happy to share. Same goes for code.