So, it’s late on a Friday in the UK and I’m in the mood to write another blog post. But I’ve just finished grinding out another day in my (soon to be ex) non-OpenSim related day job, so instead of writing something detailed, technical and real, I’m going to indulge in a bit of speculation as to what a future internet wide virtual worlds architecture might look like. This is going to be heavily influenced by OpenSim since this is the project in which I have the most experience by far (though I have played around with Croquet). And so by extension, what follows also reflects Second Life architecture, since Second Life is the scaffold upon which OpenSim has been built.
What really strikes me about the current situation regarding OpenSim deployments is the emphasis upon grids. In the current Second Life architecture, I would define a grid as a set of regions that share the same central backend services (asset, inventory, user, etc.) and which have discrete positions on a map. Some of these regions may be neighbours to each other such that an avatar can move between them without discontinuity in the 3D world (i.e. without teleporting).
The Linden Lab grid is obviously by far the biggest of these grids, containing as it does tens of thousands of regions in both contiguous ‘mainland’ areas and individual private islands. But as OpenSim has become a little bit more mature, other grids using the software have sprung up, such as OSGrid, OpenLife and the New World Grid. These grids differ a lot in their approach (e.g. OSGrid is a non-profit allowing anybody to connect, OpenLife is a closed grid with their own unreleased extensions to OpenSim), but I think that to a greater or lesser extent they all buy into the notion, inherent in OpenSim (and Linden Lab’s) current architecture, that a large grid serving many region simulators is the natural unit or organization. People owning or running these region simulators might have wildly different interests (e.g. education, sex, corporate meetings), but they’re all bound into a bigger grid entity by virtue of the services provided by the grid operators.
But if you compare OpenSim (potentially a general 3D virtual worlds server) to Apache (a general 2D web server) as is often done, this approach seems a little strange. Though it is true that the company you buy web hosting from will also provide hosting for many completely different websites, there’s little that binds these sites together beyond shared physical hardware. The hosting company doesn’t need to allocate you a slot on their grid. And when you bring up a new Apache instance, there’s no need for you to immediately hook it up to a load of support services provided by some other entity.
In a sense, you do still need a place in a map in order to host your website – in the case of the web that place is a domain name. So there is a service, the Domain Name Service, that’s necessary to support human navigation via URLs between different websites. But this is a service external to the web hosting company. In the same way, I would speculate that many of the services that are supplied by grids today (asset, inventory, etc.) will in the future be supplied by companies that can be completely independent of grid operators. For this to happen, virtual world viewers will need to interact with these services directly, rather than via a grid. Asset services, for instance, are little more than basic storage (as described in one of Adam’s experiments) that a viewer could easily deal with directly. Inventory services are a little more involved, but interacting directly with them could also make it far easier to take inventory between grids, and prevent items from being seen by a grid unless the user actually places them in a region.
Under this model, a grid goes from being a big central entity you need to hook your region simulators into, to instead being the 3D equivalent of an individual website. It could consist of a single region, or a large number of regions bound together for a common purpose. They could execute in a single region server or on many machines in a cluster (which is why I still think of these things as mini-grids rather than standalone instances). Just as with websites, you could navigate between completely independent OpenSim sites by entering urls in an address bar in the viewer. Much as with web hosting today, such OpenSim sites could be hosted by a very large number of independent hosting companies.
Linden Lab is making some steps in this direction with the Open Grid Protocol being produced by their Architecture Working Group. They have an architecture with an Agent Domain, which so far handles user logins, and a Region Domain containing the region simulators themselves. As we’ve seen with the OpenSim – Linden Lab interop work, one can log into an OpenSim region server via an Agent Domain. However, it remains to be seen as to how inventory will be supported. Making such services completely independent of grids will require some boldness on the part of Linden Lab since it could require major changes to their current business model.
If the natural equivalent of a website is an independently hosted mini-grid where most services are supplied externally, where does this leave the idea of large grids? I’m going to speculate that there could still be large grids, but that these would probably be dedicated to well-defined communities. For instance, Facebook is a huge single website dedicated to social networking – perhaps there could be a large OpenSim site along the same lines (though I have a feeling that in the virtual worlds space the situation won’t be quite so monolithic – we already see quite a few grids dedicated to individual countries and languages).
I do think, though, that the idea that OpenSim sites will be hosted on large grids of regions bound together by little more than a common backend service infrastructure is one that may well go away. Instead, URL navigated OpenSim sites could be hosted by independent companies just as website hosting is done today.