jump to navigation

A look back at my OpenSim 2010 predictions December 31, 2010

Posted by justincc in opensim, opinion, secondlife, virtual-environments, virtual-worlds.
11 comments

So, it’s that time of year again when those of us rash enough to make predictions for the year ahead get to look back and regret them.  Actually I shouldn’t say that – I think that I’ve done pretty well this year!  Or perhaps I just don’t take enough fun risks.  Anyway, on with the show.

  1. OpenSim will remain in alpha for 2010 – CORRECT. A pretty safe prediction really (assuming nothing crazy is going to happen in the last hour of this year!). OpenSim has progressed a lot since the start of 2010, but there was no serious consideration that it had moved to ‘beta’ quality during the year.  There remain a very large number of bugs and a few major missing features (e.g. the ability to take groups of separately linked objects as a single inventory item).  Moreover, a lot of internal rework needs to be done if OpenSim is going to become a general virtual worlds/environments server platform.  At the moment, the system is still too tightly tied to the needs and protocols of the Second Life environment.

  2. There will be a lot more experimentation with OpenSim in education and business contexts CORRECT. I think I can safely call this one.  In particular, since Linden Lab ended their discounts on land for education and non-profits, OpenSim (along with some other virtual environments and platforms) has seen a surge of interest from educators.  Pioneers are doing some very interesting things, such as Ener Hax and David Miller’s work on virtual science field trips.  I find this increased attention very encouraging – a massive chunk of the Internet’s infrastructure, after all, was built by universities and they could play a huge rule in constructing a genuinely distributed Internet-scale virtual environment (in fact they’re already involved as Crista Lopes, the creator of Hypergrid, is an associate professor at the University of California, Irvine).

  3. Both general-purpose and specific use grids will grow – CORRECT. I have Maria Korolov to thank for being able to assess this prediction.  During 2010 she charted a steady rise in the number of regions simulated on OpenSim grids.  Much of this rise has occurred in general purpose grids such as OSgrid.  However, specialized environments such as Jo Kay’s education oriented jokaydiaGrid have grown significantly as well.

  4. Some form of OpenSim foundation will appear, maybe more than one – INCORRECT. I thought that slowly increasing popularity and greater pressure for predictability would bring about an OpenSim-related foundation this year but I was wrong.  That’s not to say that there aren’t organizations – pretty much every grid has it’s own governing body, for instance.  But there’s no organization yet for the core OpenSim project itself.

  5. There will be a few more OpenSim distributions INCORRECT. There actually has been one new distribution – the Diva distribution – from core OpenSim developer Crista Lopes.  This packages OpenSim in a standalone megaregion Hypergrid configuration by default.  This joins the existing OSgrid distribution (which is primarily used to run a region on OSgrid).  But I don’t know of any others and I did say a few, not one, so I’m counting this prediction as incorrect.

  6. The vast majority of OpenSim access will continue to be through the Linden Lab viewer and its direct descendents – CORRECT. The Imprudence viewer (soon to be renamed Kokua) has become a popular viewer for accessing OpenSim, as they specifically provide OpenSim friendly features.  However, Imprudence is still based on the Linden Lab codebase.  Realxtend continued to develop a new viewer called Naali from the ground up and there are some interesting projects such as Rezzable’s Unity web-based viewer and the as yet unreleased Canvas web-based viewer from Tipodean.  All of these are at a very early stage, though, and a long way from the mainstream.

  7. Cross grid experimentation will continue but not go mainstreamCORRECT. There’s been continuing interest in the Hypergrid this year – an OpenSim architecture that enables users to move between installations of OpenSim that are completely separate from one another.  However, the protocol is still under heavy development – OpenSim 0.7 saw the introduction of the Hypergrid version 1.5 which is incompatible with the earlier version 1.0.  Therefore, use is still restricted to very early adopters.

  8. OpenSim will start to support mesh objects – CORRECT. In October this year, Linden Lab made their beta mesh support publicly available.  Just a week later, with the help of the libopenmetaverse library and its developers, Teravus added mesh support to OpenSim.  This support is still incomplete – chiefly because the implementation in the viewer is also incomplete – but it does give encouragement that OpenSim will have COLLADA import ability before too long.

So there we go, 6 out of 8 isn’t too bad, I think.  Tune in soon for my predictions for OpenSim in 2011.  And Happy New Year, everybody!

Advertisements

Pretty OpenSim 0.7 diagrams and updated grid setup instructions July 30, 2010

Posted by justincc in hypergrid, opensim, opensim-dev, opensim-grid, opensim-tech-basics, opinion, secondlife, virtual-environments, virtual-worlds.
9 comments

Hi folks.  Just thought I’d let you know that I’ve once again undertaken the sisyphean task of updating the OpenSimulator configuration instructions 🙂  This time, I’ve updated the grid setup instructions to reflect the current situation in OpenSimulator 0.7.  In fact, I wrote a whole new set of steps based on my experiences in setting up a very small multi-machine grid from scratch, so hopefully they should be reasonably accurate!  Of course, any improvements are very, very welcome – feel free to just edit the wiki page!

I also included some diagrams to illustrate the basic differences between standalone and grid configurations.  Here’s the standalone diagram.

As you can see, in standalone mode both grid services (login, assets, inventory, etc.) and the region simulator itself are contained within the same process (OpenSim.exe).  Viewers simply connect to this one instance.

On the other hand, even a very simple grid setup is considerably more complicated.

In OpenSimulator 0.7 a process called Robust.exe runs all the grid services.  Instead of using their own local services, each simulator (OpenSim.exe) connects to this common set of services, usually across a network.  And once a network gets involved there’s considerably more to go wrong – simulators may encounter both network congestion and a delayed response from the central services if they’re overloaded with requests.

In grid mode, simulators also need to communicate with each other.  For instance, since all regions are on a common grid, an avatar may teleport to a region running on another machine, or cross an in-world border between regions hosted on different computers.  Both teleports and border crossings involve an intricate data handoff between the origin simulator and the destination simulator.  The less reliable the network between the simulators, the worse the teleport or crossing experience will be.  Naturallly, this is often worst in the case where these simulators are communicating over the Internet.

Another interesting thing to note about this diagram is that all communication between the viewer and the virtual environment (apart from initial login, which isn’t shown here) occurs through the region simulator that the avatar is currently in.  This applies not only to things such as walking about and creating objects (both of which naturally belong there anyway), but also to operations such as inventory retrieval and texture fetch.

This is one reason why the current grid model is a centralized one, even though OpenSim instances themselves are distributed across different machines.  Anyone wanting to add a new region simulator to a grid is forced to store their assets and inventory in the single set of services provided by that grid operator – they can’t choose some independent third party or provide their own data store.  Equally, anyone adding a simulator has to be trusted by the grid operator since the guy (or gal) running the simulator potentially gains access to the assets and inventory of that grid.

That’s what makes efforts like the hypergrid, http texture fetching and VWRAP so interesting – I think that they’re all trying to lever open the door to a genuinely distributed, more web-like network of virtual environments.  A network where anybody can set up their own simulator without requiring the trust of every other operator, yet receive visitors with the same ease that one can click on a web hyperlink today.  A network where visitors retain their own appearance and are safe in the knowledge that the items in their inventory are not exposed to the simulator that they happen to be visiting (unless they rez them there).  It’s a massive challenge but one that could really transform the landscape.

Anyway, enough architectural rambling :-).  The OpenOffice draw source files for the diagrams above are linked from the configuration wiki page if anybody wants to use them further.

Predictions for OpenSim in 2010 January 15, 2010

Posted by justincc in opensim, opinion, secondlife, virtual-environments, virtual-worlds.
12 comments

Hello folks. Having assessed my 2009 predictions at the end of last year, I meant to get this post out very shortly afterwards but, as so often, life intervened :). Still better a couple of weeks late than never, so here are my predictions for OpenSim in 2010. Just to conform with everyone else, I thought that I’d use the grand word ‘predictions’ this year instead of ‘guesses’.  This doesn’t ensure greater accuracy, though :).

  1. OpenSim will remain in alpha for 2010. OpenSim has progressed pretty well over the past year.  There have been many new features and a large number of bugs have been cleared up, including some really difficult race-condition related failures. However, OpenSim is a beast of a project and many, many issues remain.  Moreover, early on in the year we’ll see some significant refactoring in OpenSim – the simulator service architecture will see its final transition to the ROBUST framework and the central scene object classes will be redesigned.  These changes are essential but in the short term they will introduce bugs of their own and force anybody already interfacing with those parts of OpenSim to adapt.
    For these reasons, I don’t think that OpenSim will emerge from alpha in 2010.  However, I do think that stability will continue to improve in the second half of 2010, leading to significant pressure to label ourselves as beta early on in 2011.
  2. There will be a lot more experimentation with OpenSim in education and business contexts. Earlier in the year, I was very interested to read just how well known OpenSim was within the UK’s higher education system.  And I know that other countries are not too far behind and some (such as Australia) are probably a little bit ahead.  So I believe that education-related use of OpenSim will grow strongly in 2010, particularly in the second half as OpenSim’s stability and usability improve.  Business and innovators will also continue to experiment with OpenSim, but from what I’ve seen they require a level of platform stability that I don’t think that OpenSim will have in 2010.
  3. Both general-purpose and specific use grids will grow. Specific use grids such as ReactionGrid, a grid oriented towards educators and collaborators, grew significantly in 2009.  I don’t see why this shouldn’t continue in 2010.  Sciencesim, another research and education oriented OpenSim installation, is also making some very interesting moves, particularly with their recent Settlement Land collaboration with the Fashion Research Institute.  This program will award educators, scientists, and researchers with a free 1/4 region of land in ScienceSim for 6 months.  Naturally, this will encourage expansion of the ScienceSim grid.
    When I assessed my 2009 guesses I wasn’t too sure whether we had seen any growth in general-purpose grids.  There hadn’t been any obvious upswing in related blogging and no data was available.  However, Maria Korolov has recently come out with some December 2009 region numbers.  Comparing these to the numbers she had back in September 2009, the largest social grids appear to show significant growth (OSGrid up by 812 regions / 30%, The New World Grid up by 106 regions / 40%), though others have shrunk or folded.  So I’m going to make the prediction that these will continue to grow in 2009, though I don’t see network effects kicking in to make that growth exponential – the platform and environment isn’t suitable for that this year.
  4. Some form of OpenSim foundation will appear, maybe more than one. Various factors (slowly increasing popularity, historically high level of churn in the OpenSim code, development unpredictability) are beginning to produce calls for the establishment of formal organizations connected with OpenSim.  These don’t necessarily need to be directly connected with core code development – ScienceSim, for instance, is working on a proposal for a foundation to support a downstream distribution using OpenSim, among other services.  It’s quite possible for organizations like this to co-exist with an Apache-like organization that surrounds OpenSim itself.
    I think that at least one such foundation will come about this year.
  5. There will be a few more OpenSim distributions. An OpenSim distribution is a project that uses OpenSim as it’s base virtual environment/virtual world platform.  At one extreme a distribution could stick closely to what is in the OpenSim core project.  At the other end of the range it could significantly alter OpenSim features and swap in its own communication protocols.
    The OSGrid distribution, for instance, is close to the core OpenSim extreme while modrex (which enables the Realxtend environment) is closer towards the other end.
    I think that we will see a few more distributions in 2010, though I predict that they will tend towards bundling code, tools or modules surrounding OpenSim rather than significantly changing OpenSim’s base functionality. I think that the economic and virtual environment sector isn’t at the right stage for the level of investment required to significantly adapt OpenSim, notwithstanding the existing Realxtend effort.
  6. The vast majority of OpenSim access will continue to be through the Linden Lab viewer and its direct descendents. I said this last year but I still think that it holds true.  In fact, as I noted in my 2009 assessment, a lot of the non-Linden derived viewer projects have fallen inactive.  There are some promising new ones but a year is not long enough, in my opinion, to get them seriously underway.
  7. Cross grid experimentation will continue but not go mainstream. Again, a prediction that carries over from last year.  Work is still being done on projects such as Hypergrid and Grider, but I don’t think that the environment is mature enough yet to bring these to more general notice.  Fundamental security issues remain with the current version of Hypergrid that, in my view, greatly hamper serious experimentation. However, I continue to think that in the long term, Hypergrid 2.0/Grider is a very promising architectural approach for a properly distributed network of virtual environments, one that overcomes the current security issues.
  8. OpenSim will start to support mesh objects. There’s significant interest in mesh objects and with the upcoming scene object refactor it will be significantly easier to support these as a native object within OpenSim.  Of course, one has to have a suitable viewer to make use of this – Realxtend’s Naali and 3di’s Rei have support for meshes and the new ‘2.0’ Second Life viewer was reported to include them too, though apparantly this is an unfounded rumour. Nonetheless, I expect that the OpenSim server will natively support the storage of meshes in some form before 2010 is out.

Accurate? My Guesses for OpenSim in 2009 Reviewed December 31, 2009

Posted by justincc in opensim, opinion, secondlife, virtual-environments, virtual-worlds.
13 comments

Hi folks.  I thought that I would spend a little bit of time today assessing the guesses I made for OpenSim back at the start of 2009.  It might be less than usually coherent since I’ve been struck down by a cold today, so please forgive that.  Next year I’ll stick my head out again and make some more guesses for 2010 :).  Anyway, here goes:

  1. OpenSim will remain in alpha for the first half of 2009, and probably for the second half as well.

    CORRECT. This wasn’t a hard call.  For a project with over half a million lines of code, I don’t think that 2 to 3 years of development is a long time.  It’s also notable that one of my missing feature examples from the start of 2009 – “allowing rez/derez of collections of objects” – is still not implemented.  However, I would say that there has been a reduction in hard race condition bugs.

  2. Lots more public OpenSim based grids will appear but growth will be steady rather than spectacular.

    INCORRECT/CORRECT. Here’s where I wish that I’d get a copy of the OpenSim grid list page from the start of 2009. The earliest version of the page still available in the wiki history is 04:55, 23 May 2009. On this date, 57 grids were listed.  As of today, there are 59 grids in this list.  Other possible sources (such as GridHop and YoSims) are less comprehensive and don’t provide historical data.

    Of course, the grid list is an extremely inaccurate proxy.  We only have ‘data’ for 7 months of the year.  People can put any numbers they like in this list and some people don’t even know about it. But it is true that some individual grids, such as ReactionGrid, have grown significantly.  For instance, Kyle Gomboy of ReactionGrid is quoted in an October 2009 piece on The Metaverse Journal that

    “On growth, since launch in January we’re up to almost 5,000 users platform wide, with over 60 independent servers and almost 500 sims platform wide, 150+ here on our world. So extrapolating to next year, we could be pretty huge hehe….”

    Maria Korolov appears to have some region numbers but these are from a point in time and aren’t useful for comparative purposes. So it’s pretty difficult to tell but on balance I’m going to venture that the absolute number of public grids has not grown significantly.  However, some individual grids (such as Reaction Grid and OSGrid) have probably steadily expanded.  I’d be very interested in any feedback from grid operators on this.

  3. The leading Second Life viewer by a very large margin will remain the Linden Labs Second Life viewer and its derivatives.

    CORRECT. On reflection, what I meant to say was that the leading OpenSim Second Life viewer would continue to be the Linden Labs viewer and its derivatives such as Meerkat, Imprudence and Hippo (though I’m informed that nobody is currently working on the Hippo viewer).

    From personal anecdotal experience I think that it is the case that Linden Lab derived Second Life viewers remain the most popular for accessing OpenSim-based Second Life grids.  Some interesting new viewers have appeared such as 3di’s Rei viewer which can operate as a web browser plugin.  Realxtend also started work on their new Naali viewer this year – a viewer rewrite that is not based on the Linden Labs codebase (unlike their previous viewer). LookingGlass is also an interesting active project.

    However, none of these have hit the core OpenSim big time (which is an extremely relative term considering the embryonic size of OpenSim).  Rei is oriented towards support for their own 3di OpenSim platform and isn’t yet compatible with Second Life features such as avatars and textures (actually it is now compatible with textures from looking at this YouTube movie and Zaki’s blog post – many thanks to JeanRicard Broek for the correction).  Naali is too new to have had any impact and is also oriented towards realXtend’s modrex extension of the OpenSim platform. LookingGlass is still a fairly new one person project right now.

    Of the viewers that Adam highlighted last in December 2008, none of them appear to be active (Xenki was last updated in April 2009, OpenViewer in February 2009 and IdealistViewer back in November 2008).

  4. Open Grid Protocol (OGP) efforts will remain almost at a standstill.

    CORRECTISH. As far as I know, OGP has effectively morphed into VWRAP (The last update to the OGP draft documents was in October 2008 last year.). VWRAP is still alive so perhaps I’m being a bit harsh, particularly as standards documents always take a long time to produce. But it’s hard to get excited about a process that hasn’t yet produced anything except a draft charter.  It’s notable that few OpenSim developers are participating in the mailing list discussions.

  5. Experiments with Hypergrid and similar cross grid architectures will continue but will not become mainstream.

    CORRECT. There has been continuing interest in the Hypergrid idea but it’s impossible to secure assets where any third party simulator is available for teleport, as outlined in the linked blogpost. Diva continues to work on the Hypergrid infrastructure but she has also started work on an ‘HG2’ Grider project.  HG2 is a second generation Hypergrid architecture where assets and other important data are delivered directly to the client rather than via a potentially malicious region simulator middleman.  In Grider’s case, this trick is managed via a proxy that wraps around existing viewers.  This project seems to be still in its early days.

  6. Linden Labs will launch their “grid behind a firewall” product but this won’t significantly reduce interest in OpenSim.

    Don’t know. Guessing the release of Second Life Enterprise (SLE) itself wasn’t exactly hard, particularly as it had already been unofficially announced. But I don’t think that there’s enough data to tell whether SLE has hurt or hindered OpenSim at this early stage of open-source virtual environment platforms. All I can say is that I haven’t personally detected any notable decline in interest in OpenSim compared to 2008, hopefully for the reasons outlined in January’s guess 🙂

  7. There will be growing corporate interest in OpenSim.

    CORRECTISH. I would say that Intel has significantly stepped up its involvement – OpenSim was featured as part of this year’s SC09 SuperComputing conference as part of their 3D Internet ‘thrust area’ :). They’ve contributed a fair number of patches and now have two people in the core OpenSim development team.

    On the other hand, IBM’s direct involvement in the OpenSim codebase has declined with the absence (temporarily?) of IBM’s OpenSim representative Sean Dague as of September 2009. We haven’t seen any other big companies step into OpenSim yet, though one always hears rumours of skunkworks projects in some big organizations.  On balance I would say that there has been uptick in interest.

  8. Later on in the year, products using OpenSim as part of an application will start to beta.

    INCORRECT. There have been occasional projects of this nature, such as Shaspa. But these don’t appear to have caught on (actually, Oliver Goh of Shaspa e-mailed me to let me know that the project is still very much alive. For instance, they’ll be at CES in Las Vegas on 7th – 11th of January and there will be a panel discussing the Shaspa framework).
    I think that 2009 was still too early for this considering the alpha nature of the OpenSim codebase and the lack of any published standards for intergrid or grid-viewer communication protocols.

  9. There will be considerable growth in third party OpenSim modules this year.

    INCORRECT. On the OpenSim forge, 10 projects have been registered since the middle of July 2009. Of these, 1 was a region module project. Linear extrapolation makes for 2 modules this year, which isn’t very many.

    I’m not sure exactly why this is.  There are probably lots of contributing factors; a lack of documentation for region modules, the still embryonic nature of OpenSim, more interest in projects surrounding the simulator (such as monitors and automatic deployers) rather than embedded within it. The forge itself is also likely another inaccurate proxy but I don’t know of a better one.

I’m going to charitably call this 61% (5.5/9) which is a pass mark I think :).  Any comments/agreements/disagreements/clarifications are very welcome.  Other than that, I hope everybody has a Happy New Year and a prosperous 2010!

The Tao of OpenSim April 11, 2009

Posted by justincc in opensim, opensim-dev, opinion, virtual-environments, virtual-worlds.
7 comments

opensim-logo-short-yin-yangIn today’s long and rambling post I want to address two topics which have come up for me recently.  The first is the assumption that OpenSim is just trying to be a cheaper Second Life.  The second is the idea that OpenSim development is something that will inevitably be provided by other people and companies.  I think that both of these are wrong, and here’s why 🙂

OpenSim doesn’t aim to be a Second Life clone

From the outside, I think that it’s easy to get the impression that we’re trying to produce a Second Life clone.  We implement the LSL language and many of its functions, we provide an environment which is used with Second Life clients, we provide a ‘grid’ architecture with many regions relying a set of centralized services (asset, inventory, etc.).

But the real aim of OpenSim is to go beyond this to provide a general 3D ‘virtual environment’ platform.  As well as the classic ‘grid’ configuration, we provide a ‘standalone’ configuration where the entire system is run on a single machine, which is more suitable for some types of virtual environment applications.  We also have an experimental ‘hypergrid‘ mode where individual OpenSim installations can be hooked up to each other whilst retaining their own asset and inventory services.

Another aspect to our general platform goal is to enable the use within OpenSim of different client protocols or even different virtual environment types such as VastPark.  Most of this support will come from plugin modules.  But inevitably it will also require extensive support in the core project code.

Making the necessary changes won’t be easy.  OpenSim has grown up around the Second Life client and inevitably reflects the Second Life architecture.  For instance, the Second Life client references a user’s profile via that user’s Universally Unique Identifier (UUID), as assigned by the server.  But another client protocol may identify a user profile via a unique URL instead.  Even such a seemingly small difference has big ramifications – the server code uses UUIDs to reference user profiles right down to the database layers and all this needs to be made more generic.  Larger differences would be more difficult yet.  Nonetheless, I believe that the generic platform goal is an extremely good one, since it can take OpenSim beyond a single niche and make the code useful in many more situations.

OpenSim is driven by the many, not the few

One reason that we can maintain such a goal is that unlike some other open source virtual world/environment projects, there is no single company behind OpenSim.  There’s not even a single group of companies – just like the Linux kernel, our contributors are wonderfully diverse, ranging from paid and volunteer development from IBM through to single contributors employed at startups and people who contribute just for the (masochistic 🙂 fun of it.  And contribution rates are heavily skewed towards the individuals.

Partly also because the project isn’t backed by a single company, we don’t follow the common practice of releasing GPL code whilst retaining the right to also license that code  commercially.  Instead, all of our code is available under the BSD license for anybody to use as they see fit (including incorporation into proprietary paid-for products).

This situation can be seen as both a strength and a weakness.  It means that roadmaps and release schedules are harder to come by – nobody has enough developers or central authority to guarantee that dates and features points are met.  It means that there’s no legal mechanism for ensuring that development comes back to the community (which can be seen both as a good and a bad thing).  It means that the development team is not ‘professionally’ managed by a set of executives focussed keenly on the customer.

But the flip side of this is that OpenSim really is driven by the development community – anyone can submit a patch to any area of the code.  Such patches are subject to review on a voluntary basis by core developers and this is far from a perfect process – different developers may have different views on the same patch, and occasionally patches languish.  However, it does mean that potentially anyone can influence the project – there should never be any conflict because of an internal commercial interest.  And even features which aren’t suitable for the core distribution should be implementable using the module system, either now or in the future as that mechanism improves.

This purely community driven model also means that often things get done in OpenSim only if someone has a particular interest or idea that they want to pursue.  This might sound like a bad thing, but it has got us where we are today.  So if you’re able to write code and there’s some feature that you think should be in the core OpenSim codebase, or you see some bug that should be fixed, then please jump in!  There’s no guarantee that it will be easy – the more radical the feature, the more difficult it is to get it in (this actually tends to act as a stablising influence).  But without such a contribution it may be a long time until that feature or bug fix gets done – it may even never get done at all.

Having said all this, I do recognize that this means of steering OpenSim doesn’t directly account for the many talented people out there who don’t happen to be developers.  That certainly doesn’t mean that there is an absence of influence from them – conversation about problems or desired features drives the common debate and so affects the code that eventually gets written.  Is this enough?  I think that’s actually a very complex question and I honestly don’t know, though I do think that the base of user influence will broaden as time goes on, either in OpenSim directly or in downstream projects that use OpenSim as a component.

Is a Universal Virtual Worlds Viewer possible? March 20, 2009

Posted by justincc in opensim, opensim-dev, opensim-grid, opinion, secondlife, virtual-environments, virtual-worlds.
add a comment

Introduction – the Problems of a Universal Viewer

earth-mars

In common with quite a few other people, I’ve speculated before about a very different internet architecture for virtual worlds from that of the current Second Life.  Instead of virtual worlds comprised of big ‘grids’ of simulators sharing central services, there would be a much larger number of independent virtual environment ‘sites’ on the internet.  You could visit a site just by typing its URL into a viewer’s address bar.  Your virtual environment inventory and appearance would not be maintained by any particular site – instead it would come directly from your own machine.

As you can see, this very much parallels the way in which one visits websites with a web browser today.  But for this to work, there must be a single set of protocols to provide virtual environment functionality (much as HTTP and HTML provide common web functionality today).  And if one is to get to this single set of standards then the virtual environments that it encompasses need to have a fair amount in common.  The only problem is that different virtual environments arguably don’t have all that much in common.

For instance, suppose that you find an LSL (Linden Scripting Language) script which allows you to close, lock and unlock a door.  This script runs quite happily in the virtual environment of site A.  However, you then take that into your inventory and then decide that you want to also use it at site B (let’s ignore both the question of whether LSL is a desirable language to use and the broader issue of running user scripts at different sites).

In order to run that script at site B, that site would need to provide a suitable execution environment.  Among other things, it would need to

  • Provide an event model which can provide touch, timer and sensor events
  • Understand that UUIDs can be used to reference sounds and textures in the system
  • Know that speech can occur on different ‘channels’
  • And provide a way for ‘objects’ to communicate messages between themselves.

Naturally, there isn’t much of a problem if site B is running exactly the same protocols as site A (e.g. site A is OpenSimulator with the Second Life protocol and site B is a Linden Lab system).  But what if site B is operating on another platform, such as Project Wonderland?  In order to run that script on a Project Wonderland site, it would need to be able to emulate all the bullet points above as well as provide the ability to execute the LSL.  I’m not familiar with the architecture of Project Wonderland but I’m presuming that some of this could be quite awkward, possibly to the point of impractability.

Of course, LSL and Second Life script execution environments aren’t a fixed point.  It may be possible to come up with a compromise common execution environment that spans different virtual world architectures, though this is far from a foregone conclusion without getting into the really nitty-gritty details.

Execution environments are, however, just the tip of the iceberg.  Different virtual environments may also have

  • Different ways of matching processing power to topology (e.g. they won’t tie machines to emulating fixed size regions)
  • Fundamentally different ways of graphically representing objects (e.g prims versus meshes)
  • Or even a completely different system architecture (e.g. Croquet’s peer-to-peer approach versus Second Life and Project Wonderland’s client-server architectures).

It is difficult to imagine how a single set of protocols could span rather disparate systems.

LESS is more? (groan)

Jon Watte, the CTO of Forterra Systems has a very interesting alternative to the one protocol fits all approach.  This is the LIve Entity State Stream (LESS) protocol that has recently been batted back and forth in the Internet Engineering Task Force’s (IETF) Massively Multiplayer Online X (MMOX) mailing list.  Rather than specify the protocols for a large part of the virtual environment in order to enable direct inter-world avatar travel (as the Linden Lab initiated Open Grid Protocol (OGP) tends to do), LESS aims to establish telepresence between disparate worlds.  Instead of travelling directly to another environment, a space in your local environment would be set up to mirror a space in the remote environment (that is, if there is a cube in the remote environment at relative co-ordinates of (2,2,2), you also have a cube in your local environment at (2,2,2).  State changes for these objects in the remote environment are mirrored in your local environment (e.g. if the remote cube moves to (4,4,4) then your local mirror cube is moved to (4,4,4)) and vice versa.

This avoids the problem of having to harmonize rather different virtual environments.  It may also have security advantages – if company A using Second Life and company B using a Forterra Systems installation want to hold a joint virtual meeting, then they don’t need to both implent a universal protocol and allow direct system access for each other’s users.  Rather, they could just establish a temporary telepresence connection between the two systems that could be torn down once the meeting was over.  In a very small way my own Parallel Selves Message Bridge mirrors this approach since it transmits Instant Messages between proxy selves on different systems, rather than directly via some shared common mechanism.

But just as telepresence in real life is somewhat lacking, so may be virtual telepresence (leaving aside any remarks about any virtual environment being less satisfying than a real one :).  The dream of being able to freely move between virtual worlds, as we’ve seen from the popularity of the Second Life teleport experiments and OpenSim’s own Hypergrid architecture, is a pretty strong one.

Conclusion

There may well be room for both common clients and virtual telepresence, at the cost of abandoning any idea that there will be a single universal client for accessing every virtual environment.  Those environments that are similar enough to implement a common protocol can share a common viewer.  Where the incompatibilty between environments is too great to overcome, or even for other reasons such as greater security, a virtual telepresence approach could be employed to share communication and simlulations between virtual worlds.

Reflections on Writing an OpenSim Region Module February 27, 2009

Posted by justincc in opensim, opensim-dev, opensim-modules, opinion, psmb.
13 comments

Introduction

opensim-logo-shortA couple of weeks ago I mentioned that I planned to post something about my experiences in writing the Parallel Selves Message Bridge module.  This is that post, albeit a little bit later than planned 🙂  It isn’t a region module writing tutorial – the OpenSim project wiki has one of those if you’d like to read about that.  Nor is it an explanation of the technical guts of how the bridge itself works (for which I recommend reading the source code – it’s actually not very complicated).  Instead, this is a reflection on what I encountered while hooking up a ‘third party’ module to OpenSim (since the PSMB isn’t included in the core OpenSim distribution).  I’m going to describe some of the basic process I went through, and then talk about what I found good, bad and ugly.  In other words, I’m telling you what I think about eating our own dogfood 🙂

The Basic Process

The first thing I did when writing the PSMB was to create a class that implemented OpenSim’s IRegionModule interface.  IRegionModule is very simple – it’s the means by which OpenSim passes you a Scene class that represents each region in the server.  Here’s how the PSMB handles this (with some bits cut out for space reasons).

public void Initialise(Scene scene, IConfigSource source)
{
    IConfig config
        = source.Configs["Parallel Selves Message Bridge"];            

    if (!config.Contains("target_system_name"))
    {
        m_log.Error(
            "[PSMB]: You must specify a target system name!");
            return;
    }

    if (!config.Contains("target_system_uri"))
    {
        m_log.Error(
            "[PSMB]: You must specify a target system uri!");
            return;
    }

    m_targetSystemName = config.GetString("target_system_name");
    m_targetSystemUri = config.GetString("target_system_uri");

    scene.EventManager.OnMakeRootAgent += OnMakeRootAgent;
    scene.EventManager.OnChatFromClient += OnChatFromClient;
    scene.EventManager.OnClientClosed += ClientLoggedOut;
}

Let’s focus on the bottom three lines for a second.  This is where the PSMB module is hooked up to certain events in the scene.  For instance, scene.EventManager.OnMakeRootAgent is fired whenever an avatar enters that region, whether by initial login, region crossing or teleport.  Here’s the OnMakeRootAgent() method that I’ve hooked it up to.

private void OnMakeRootAgent(ScenePresence presence)
{
    lock (m_activeBridges)
    {
        if (m_activeBridges.ContainsKey(
            presence.ControllingClient.AgentId))
        {
            Bridge bridge
                = m_activeBridges
                    [presence.ControllingClient.AgentId];
            bridge.OsClient = presence.ControllingClient;
        }
    }
}

As you can see, the fired event passes on a ScenePresence that you can use to find out more information about that avatar (for instance, its name).  In this case, I need the agentId so that I can make sure that the bridge keeps talking to the right client connection after the user has crossed a region border.

In my module I also wanted to know

  • when an avatar said something, so that I could intercept the commands to connect and disconnect the bridge (so I subscribed to OnChatFromClient)
  • when an avatar logged out, so that I could automatically disconnect the bridge (so I subscribed to OnClientClosed).
  • when an avatar sent an instant message so that I could reroute it to the target system if necessary (so I subscribed to IClientAPI.OnInstantMessage, not shown here).

This is all I needed to do to get all the event notifications that I needed.

The other part of the Initialise() method concerns configuration.  From IConfigSource I can get at any information in OpenSim.ini, so I used this so that people could configure the target system that they wanted for the bridge.

Receiving events from OpenSim is only one part of the equation, I also needed to invoke certain OpenSim services.  For instance, the bridge needs a ‘proxy’ user in the source system for every friend that the user has in the target system.  I did this in the PSMB with the following bit of code.

CachedUserInfo userInfo
    = m_scene.CommsManager
        .UserProfileCacheService.GetUserDetails(userId);

if (null == userInfo)
    m_scene.CommsManager.UserAdminService.AddUser(
        firstName,
        string.Format(
            "{0} ({1}),", lastName, Config.TargetSystemName),
        UUID.Random().ToString(),
        BRIDGE_GRID_EMAIL,
        1000,
        1000,
        userId);

In this case, the Scene class has a CommsManager that provides certain services (user information, inventory manipulation, etc.).  Using the CommsManager I first ask the UserProfileCacheService if a user I’ve been told about by the target system (represented by userId) exists in the source system.  If not, then I use the UserAdminService to add that proxy user.

As well as adding the proxy user, I also need to make the PSMB module send the user a ‘friend request’ so that their friends on the target system can be added to their local friends list.  In this case I needed to use a slightly different looking OpenSim facility

IFriendsModule friendsModule
    = m_scene.RequestModuleInterface<IFriendsModule>();
friendsModule.OfferFriendship(
    userId, OsClient,
    "Initial setup populating offer from the PSMB");

Here I’m actually invoking another region module (the Friends module) rather than a ‘service’.  These region modules are obtained by asking for something that implements the right interface (here IFriendsModule).  Once I have this interface, I can invoke the module to handle the friendship offer.

psmb-diagram1

The Good

As IRegionModule is nice and simple, it was easy to implement the basic module infrastructure.  Getting information from OpenSim was also without trauma – all the right events already existed and were giving me the appropriate information.  It was also easy to get configuration data, as you can see above.  Although I didn’t use them in this module since I didn’t need them, there are also fairly simple ways of adding extra commands that can show in the OpenSim console.

It’s also always possible to get hold of the services and other region modules that one needs to invoke, though it’s much more difficult to work out which ones you actually need (as discussed in further detail below).

Although I didn’t mention this above, it also wasn’t too difficult to copy the OpenSim build infrastructure in order to build the PSMB module indepedently from the core product.  This is a different approach to inserting the module code directly in a copy of the OpenSim source tree and building it there (which is what I suspect some other modules do).  To me, building the module separately is much cleaner, though it was a matter of trial and error to detect which OpenSim DLLs I needed.

The Bad

One particularly bad thing is that OpenSim passes in its Scene object directly, rather than via an interface.  This is handy for getting at all the methods one could need, but it also exposes a lot of code that is either

  • irrelevant to region modules or
  • misleading (for example, there is a Scene.AddSceneObject() which won’t do what you expect – Scene.AddNewSceneObject() is what you want!)

To some extent this could be resolved by passing in the scene with an IScene interface instead (and hence restricting the methods that can be invoked).  But really OpenSim would also need to properly sanitize methods on the objects that one can then retrieve from IScene (including services available from IScene.CommsManager).  Among other things, manipulating objects in the scene is particularly hairy and hard to do at the moment.  I’m quite lucky in that I don’t need to do any of that in the PSMB module.

All of this isn’t helped by the fact that large parts of the OpenSim codebase are currently undocumented.  That isn’t too much of a problem for me but it’s going to make life much more difficult for people who want to implement a module without getting intimate with large chunks of OpenSim core code.

A final thing that I would count as a ‘bad’ right now is that OpenSim code is in a considerable state of flux.  Indeed, after releasing the PSMB module I very quickly had to make another release in order to deal with a change in OpenSim namespaces.  I also know that the IRegionModule interface is due for an overhaul and that all the services mentioned above are probably going to be made into modules instead.

At the moment this kind of thing is inevitable and I really don’t think it could be any other way – OpenSim is an alpha project and isn’t ready to hammer down its interfaces.  But it’s worth bearing in mind that if you write a region module that you want to work over a wide range of OpenSim versions, then right now you’re going to have to be prepared to potentially do some rework when OpenSim versions are released.  This problem is worse if one is tracking OpenSim’s latest and greatest code (SVN trunk).

The Ugly

The PSMB module works by accepting connect and disconnect commands through the chat interface.  Instant Messages are intercepted and routed to and from the target system as appropriate.

However, OpenSim currently provides no way of letting a module signal that they have handled an event in such a way that it shouldn’t be passed on to other modules.  For instance, since connect commands contain passwords I don’t want them to be said out loud by OpenSim’s ordinary chat module.

To stop that happening I had to resort to completely replacing OpenSim’s ordinary chat and IM modules with my own versions.  This is deeply ugly since it makes configuration more difficult, and makes it virtually impossible for the PSMB module to interoperate with other code that also wants to filter certain events.

Conclusion

It’s unfortunate that I’ve made the bad and the ugly sections in combination longer than the good – really there are quite a few nice things about writing region modules that on the whole make them perfectly useable at the moment, as long as one is prepared to spend quite a long time studying both example code and the core OpenSim codebase itself.  The amount of time that one needs to spend is dependent on what one wants to do (doing something with chat is easy, manipulating scene objects is much harder).

I suspect that this will continue to be the case in the short term as there is quite a lot of OpenSim restructuring on the horizon.  Some of that will actually address the things that I’ve complained about (such as passing in Scene directly and the absence of any way to filter event propogation).

One thing that I do find perturbing, however, is that not many people write class or method documentation.  In some cases this is arguably overkill.  But when one wants to expose interfaces to people who aren’t OpenSim core coders then I think that it becomes essential.  My hope is that as the project matures more people will come around to this point of view.

Guesses for OpenSim in 2009 January 9, 2009

Posted by justincc in opensim, opinion.
7 comments

opensim-logo-short-with-question-markSo, I thought I’d somewhat belatedly indulge in that favourite blogging staple, predictions for the coming year.  In my case, I’m going to stick to speculation about OpenSim (or speculation about events that may affect it).  And in the interests of truth in advertising, I’m going to call these guesses as they’re based largely on gut instinct.

I’d also like to emphasize that these are my personal views and not necessarily those of any other OpenSim core developers or community members 🙂

Things that may just happen in 2009

1.  OpenSim will remain in alpha for the first half of 2009, and probably for the second half as well. Although OpenSim is progressing well, there are still a lot of bugs in the code base, some missing features (e.g. user groups, allowing rez/derez of collections of objects), and various aspects of the user interface that are very rough and ready (like the console command system and the API for region modules).  Also, the really nasty bugs (especially those relating to race conditions and performance) will take a long time to pin down and eliminate.  Therefore, I would be very surprised if we emerge from alpha in the first half of this year.  I think there’s a small possibility that we may go to beta late in the second half.

2.  Lots more public OpenSim based grids will appear but growth will be steady rather than spectacular. Quite a few OpenSim based grids have come up already.  However, I think that we’ll see considerably more this year.  They’ll range from fairly (though not massively) well funded efforts down to those which run on a couple of servers in somebody’s closet.  Not that there’s any reason why some of the latter won’t be very professionally run, but the majority of grids will remain small – overall population on grids using OpenSim will grow steadily but not exponentially.  I don’t think that any grid will dominate – the market that exists is too immature for that.  Some grids will try to distinguish themselves from the competition by providing specialized features and viewers.

3.  The leading Second Life viewer by a very large margin will remain the Linden Labs Second Life viewer and its derivatives. There are some viewer projects underway that don’t use the Second Life viewer code base at all.  However, a vast number of man years has gone into the Linden Labs viewer, so I think that it and viewers derived from its codebase will remain the ones that the vast majority of people will use in 2009.  I’d loved to be proved wrong on this since I think that a viable alternative viewer would be the first step towards codifying protocol specifications of some kind.

4.  Open Grid Protocol (OGP) efforts will remain almost at a standstill. My impression is that there’s been a significant drop off in Linden Lab’s Open Grid Protocol activity now, after completion of the initial first steps of being able to teleport avatars between a Linden Lab beta grid and suitably OGP enabled OpenSim instances.  I think that with the current recession, much of their activity has been diverted from risky activities that don’t promise any short term return (such as OGP) into projects which are more likely to produce immediate growth and revenue for the company.  Therefore, I don’t think that there will be any revival of OGP activity in the first half of 2009, though possibly there might be some renewed work in the second half of the year.

5.  Experiments with Hypergrid and similar cross grid architectures will continue but will not become mainstream. There has already been considerable interest in OpenSim’s experimental Hypergrid architecture for linking grids (and standalones) together.  I think that we’ll see considerable experimentation and development of this in 2009.  However, though I think that the remaining technical bugs are resolvable (such as the failure to rez the inventories of objects), there remain considerable security and intellectual property related challenges with the architecture.  It will take a lot of work to resolve this and even to determine the extent to which these can be resolved.  Therefore, I think that we will see much use of hypergrid in commercial grids in 2009.  There will also be continued experimentation with alternative multi virtual environment architectures, such as that where assets and inventory is maintained directly by users rather than by grids.  However, none of these will be ready for prime time in 2009.

6.  Linden Labs will launch their “grid behind a firewall” product but this won’t significantly reduce interest in OpenSim. I think that Linden Labs will launch a beta of this product this year, as CEO Mark Kingdon unofficially announced.   For two reasons, I don’t think that it will have an enormous impact on OpenSim.  Firstly, I suspect that it’s going to be pretty highly priced, especially as it’s been developed in conjunction with IBM.  Secondly, I also think that it will remain proprietary rather than become open source.  In combination with the price tag, this will mean that even within a company that buys this product, creative individuals won’t be able to simply pick it up and start running their own region servers and grids.  Even getting some sandbox space to play around in may involve going through a bureaucratic process.  A proportion of these individuals will prefer to pick up and run with OpenSim instead, especially as they can still migrate content developed there over to the official corporate solution.

7.  There will be growing corporate interest in OpenSim. Speaking of corporate interest, we already have quite a few large companies contributing and experimenting with OpenSim both officially and unofficially (such as IBM, who have core development members and Intel, who contribute significant patches).  I think that this will grow in the coming year, both in terms of relatively small content development companies such as Rezzable and in experimentation and maybe even official participation by larger companies (for instance, Jeff Barr, the Lead Web Services Evangelist at Amazon, obviously has an eye on OpenSim).  This will enrich OpenSim and help push OpenSim forward, though a very high proportion of development will continue to come from very talented individuals who aren’t working for a large corporation.

8.  Later on in the year, products using OpenSim as part of an application will start to beta. One exciting thing about OpenSim is that it’s not just a virtual world platform – the aim is to be a platform that’s a good basis for all kinds of applications that require virtual environments.  We’ve already seen some early experimentation in this area, such as IBM’s 3D data center.  I think that the coming year will see a few more such announcements, though I believe that the numbers will remain low for now (disclaimer, I work for a company that is doing exactly this).

9.  There will be considerable growth in third party OpenSim modules this year. One of the aims of OpenSim is to have a modular architecture into which people can plug in their own code without having to get patches into the core codebase.  Although our architecture and API for doing this are currently far from perfect, we have already seen a number of third party projects created, many of which are hosted by the OpenSim Forge set up by Adam Frisby for OpenSim related code.  This trend will continue in 2009, though in my opinion it will be most significant late on in the year as module support improves and OpenSim matures to the point where some of the APIs can be stabliized.

Conclusion

Now that I’m looking back on the predictions I’ve written, most of them are pretty conservative (maybe part of me just doesn’t like to be wrong :).  Like Gwyn, I think that this will be a strong growth year for OpenSim but not a breakout one.

The democratization of virtuality September 26, 2008

Posted by justincc in opensim, opinion.
7 comments

Anybody reading this blog may have noticed that I haven’t posted anything much for the past few weeks, apart from weekly OpenSim development summaries.  The truth is that I’ve wanted to but just haven’t been able to get the time – as I’m sure everyone knows, travelling and starting a new job tends to leave very little room for anything else :).  Today I’m hoping to get back on my not-exactly-hectic two week cycle of writing.  Having said that, this is going to be one of those somewhat fluffy opinion oriented posts, though next fortnight I’m hoping to write something about the OpenSim region archive (OAR) work that’s been going on in the project recently.

OpenSim as a democratizing project

One of the reasons I originally got involved with OpenSim was a funny kind of idealism.  Part of this was the inescapable logic (well, inescapable for me. at least) of open source.  If one contributes to an open source project then the potentially immense amount of utility that other people can get out of using, inspecting and building on that contribution easily outweighs any personal short-term cost.  Of course, one still wants to eat, be sheltered and have nice things, which is one reason I still have to do some other work for a living :).

In OpenSim’s case this logic is augmented by the fact that one is helping to build virtual environment infrastructure with a potentially immense number of uses.  As I’ve blogged before, these range from embedded and standalone applications, such as IBM’s IM embedded 3D spaces or Black Dress Technology’s apparel design software (disclaimer: I’m lead developer for BDT) through to the creation of large socially oriented virtual worlds in which people can create and sell the 3D objects that they create.

Moreover, by making the base technology malleable and open source, the cost of experimentation and production comes down to very low levels, low enough to enable such actitivites for very small groups or even individuals.  I think that the potential for innovation and creativity is evenly dispersed throughout the entire population regardless of wealth or education – the thought that we may be able to help people express that and build great things for all us is a very exciting one.

This is what I mean by the democratization of virtuality – allowing individuals and small groups to run servers, create communities and build applications.  Is OpenSim there yet?  Not really – it’s still pretty complicated to set up and the code quaility and functionality is still at the alpha (not even beta) stage.  But progress is rapid and I think the project has very good potential for helping to bring the development and hosting of virtual worlds to everybody.

OpenSim as a mechanism provider rather than a policy setter

However, what I think that we will be keen to avoid is any notion that OpenSim will set policy for the people using it.  Dusan Writer has written extensively on this topic, and I don’t want to write anything too much myself until I’ve fully absorbed the arguments (I’m still catching up on blog reading as well as writing!).  However, I think there are many reasons why OpenSim itself will always avoid a notion of providing any kind of virtual worlds policy.  For starters, OpenSim isn’t meant to simulate just virtual worlds with mass avatar participation, but also other kinds of application oriented virtual environments as we disuccsed earlier.  For the latter type of application, policy enforcement may make very little sense.

Secondly, OpenSim is a broad church incorporating lots of developers with different interests.  The chances are that some people would have very different ideas of what virtual worlds policy should be, while others would have no interest in it whatsoever.

Thirdly, OpenSim has always had the intention of being a modular toolbox for creating virtual environments.  In so much as mechanisms for enforcing policy are provided (such as, prosaically, prim limits on land parcels or the ability to allow some users to kick off other users), their use will very probably always be optional in nature, leaving it up to the individual or organization running the virtual environment to enable or tweak as they see fit.

Having said this, I do accept that there may be some basic architectural decisions which do affect how virtual worlds develop.  A good proportion of these are in the hands of groups concerned with producing standards for running grids (such as the Linden sponsored Architecture Working Group).  In many cases OpenSim will be able to adapt to these different standards by adopting different communication modules without requiring any changes in the core parts of the platform.  However, there may be some decisions which are on such a fundamental level that they affect the very basis of the software itself (such as the choice between a server-client architecture and a more Croquet-like peer to peer approach).  To my mind, it’s not at all clear yet as to what these fundamental issues (if any) are – I suspect that they will only emerge over time, and then only with real world experimentation.

Could there be a future without big grids? August 15, 2008

Posted by justincc in opensim, opinion.
18 comments

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.