addressing places in virtual worlds...or: why SLURLs are bad

we currently are using LindenLabs’s SecondLife clients (and derivatives thereof) to login to and render our OpenSim based virtual worlds. as the SecondLife client is produced by LindenLabs for their SecondLife grid, it should come as no suprise that their client by default only talks to their grid(s). however, it is possible to tell the SecondLife client to connect to one of our grids…

…but the method is not very user friendly and rather requires “specialist” know-how — which is fine for developers but not really appreciated by normal users.

another issue that we face is addressing virtual world places in non-LindenLab grids: the SLURL way of doing this unfortunately works with the LindenLab main grid only, as it just translates the SLURL into a secondlife:// URI which addresses not a grid but the secondlife client itself and does not convey any information whatsoever about the grid on which the place is hosted. :-(

so, we looked for a way to (a) simplify things and (b) allow us to address places in any virtual grid. we created a new URI scheme, the rezzme:// URI scheme (URIs are kind of the glue that ties the internet together: everytime you click on a link such as http://opensim.zurich.ibm.com/ you are using an HTTP URI).

rezzme:// URI scheme

each rezzme:// URI follows the scheme suggested by RFC 2396 and can either

  • address just a grid:

    rezzme://opensim.zurich.ibm.com:9000/
    
  • address a grid and a region on that grid

    rezzme://opensim.zurich.ibm.com:9000/zurela
    
  • address a grid, a region, and an X/Y/Z location in that region

    rezzme://opensim.zurich.ibm.com:9000/zurela/128/34/23
    
  • address a grid and include the avatar’s name:

    rezzme://Dr%20Scofield@opensim.zurich.ibm.com:9000/zurela
    
  • address a grid and include the avatar’s name and password:

    rezzme://Dr%20Scofield:S3CR3T@opensim.zurich.ibm.com:9000/zurela
    

here’s an example rezzme:// URI:

    rezzme://opensim.zurich.ibm.com:9000/aluminium/128/128/33

rezzme:// protocol handler

the rezzme:// URI scheme by itself is just half the story: you need to have a protocol handler. luckily there is a “reference” implementation available over at the rezzme project on OpenSimulator.org’s forge for both linux and windows. it does require PyQt4 to be installed — you can however create a windows binary that has everything bundled.

the rezzme:// protocol handler parses rezzme:// URIs and extracts the grid server part. using the grid server part — opensim.zurich.ibm.com:9000 in the example above — it then attempts to obtain that grid’s GridInfo block via REST from the grid server and, if successful, uses the login URI information from the GridInfo block to configure the secondlife client (if it could not retrieve a GridInfo block it will use the grid server as specified in the rezzme:// URI instead).

if the rezzme:// URI included place information (region/island, X/Y/Z coordinates), the protocol handler will create a suitable secondlife:/// URI for the secondlife client.

other virtual world platforms

rezzme:// URIs are not just addressing OpenSim grids, far from it: the GridInfo block contains a platform value that is “OpenSim” for OpenSim based grids, but could be “SecondLife” for Linden Lab grids, or “ActiveWorlds” for active world grids. the reference protocol handler currently does not (yet) support values other than “OpenSim” or “SecondLife” but could easily be extended.

rezzme protocol handler features

other features of the rezzme:// protocol handler:

  • bookmarking of rezzme:// URIs (including editor and quick access via system tray icon)
  • support for external authentication mechanisms
  • support for selecting and using different clients (different versions of the secondlife client, hippo client)

other schemes

aside from the already mentioned SLURL mechanism, there’s the OSURL scheme which is very similar to rezzme:// URIs but (currently) restricted to OpenSim grids.