Why Second Life OGP is not a vendor neutral interoperability protocol

Mark Lentczner of Linden Lab has posted the draft description of the Second Life / OpenSim Open Gateway Protocol (OGP) at http://www.ietf.org/internet-drafts/draft-lentczner-ogp-base-00.txt. It is billed as a vendor neutral virtual world interoperability protocol.

Unfortunately, it does not provide vendor neutral interoperability.

In the OGP model, a client will connect an agent domain (something like a sign-in server), which will inject various pieces of content from storage (something like object repositories) into region domains (something like simulation servers). The client will then receive a view of the simulated object and connected region.

For this to work, the description of the object in the object repository must match the requirements of the execution environment of the simulation server. Further, the client of the simulation must understand the simulation view protocol used by the simulation server to display the outcome of the simulation to the user. Finally, for a given region of space, only one simulation server is used, leading to a single-world ownership of a single point in space.

This means that, if we were to implement OGP into the OLIVE system, we would achieve exactly zero interoperability with non-OLIVE-derived technologies. Similarly, OGP implemented in Second Life and OpenSim achieves exactly zero interoperability with non-Second-Life-derived technologies. The fact that object description, execution environment and client view protocol all need to belong to the same technology family when using OGP, makes OGP not only not provide vendor neutral interoperability, it actually drives interoperability down the path of a "unified client" -- for a single client to be able to partake of different content in different worlds, that client needs to understand the simulation view protocol of all those worlds. Further, it drives interoperability down a path of "moving objects around" rather than actually interoperating at the simulation level, driving interoperability towards a "single execution environment model."

Several times, I have pointed this out to Meadhbh Hamrick and Mark Lentczner, both in public on the IETF mailing list, and in private e-mail, but I have not yet gotten a reply that actually addresses these specific concerns. On the list, the reply is (paraphrased) "we believe that the standard is open, and therefore provides vendor neutral and interoperability;" of the list I have only received silence.

Both of those goals: a unified client, and a single execution environment model, turn out to be expensive ways of achieving very little when it comes to cross-technology, vendor neutral virtual world interoperability. As an alternative, I have for a long time advocated a server-side gateway/peering approach, which achieves robust, interactive interoperability in a scalable way across multiple different technologies, without any change in execution environment or simulation view protocol for any participating world. You can read more about it at http://www.interopworld.org/vwsis and http://www.ietf.org/proceedings/staging/draft-ietf-mmox-less-protocol-00.txt

If you're interested in true, vendor neutral, cross-technology interoperability, it seems like right now there is no good forum for that discussion. The MMOX list, while chartered as a "vendor neutral" list, certainly does not provide it.