today's VWRAP essentials post is for a more technical audience. if you're reading this, i'm going to assume you're familiar with VWRAP, the Virtual World Region Agent Protocol. if you need a refresher, you can look at "what's VWRAP?" post on this blog, read the VWRAP Working Group Charter, or read the latest draft of the "VWRAP : Intro and Goals" document.
early in the list of technical deliverables for the VWRAP working group is the document titled "abstract type system for the transmission of dynamic structured data." in this post we're going to answer the question "what is an abstract type system and why should i care?"
c? c++? python? c#? php? javascript?
so there are a bunch of languages used by virtual world programmers. which one should we standardize on? if you answered "we shouldn't standardize on any of them," then you gave the right answer. VWRAP is a wire protocol intended to be implementable by any language. if you can open a network socket and receive arbitrary HTTP requests, we're hoping you can use it to implement VWRAP.
but this introduces a bit of a quandry. the type behavior of languages is mildly different. integers in c are 32 bits in length, unless they're 16 or 64. JavaScript seems to not have a limit, transparently converting regular integers into multi-precision integers (except when it doesn't.) and in some languages the results of adding integers to strings isn't the same as others.
while most languages provide a plethora of types (like integers, strings, dates, etc.) the rules for adding them together or converting them to other types are inconsistent. in normal development this isn't too much of a problem; on the rare occasion programmers have to code in different languages, there are frequently tools to manage the differences. these tools usually only work on a specific system, however. they're designed not to work in the general case, but tailored for a particular development environment.
it's still really nice to be able to use familiar types like integers, strings, dates and so on when describing protocol messages. but if there's no easy way to convert between types used in different implementations, what do you do?
the LLSD abstract type system
an early version of the LLSD abstract type system was introduced internally in 2005 and was intended to hide type system differences between C++, python and ruby based services. the intent was to store structured data independent of language-based type behavior. when a python program read data written by a C++ program, it would know what the rules were. integers were ALWAYS 32 bits wide. dates were ALWAYS stored in the same format; not a 32 bit int on some systems or a string on others.
over the past five years, LLSD has been refined somewhat, but the basic rules are the same: there are a fixed number of types that all languages SHOULD be able to understand. there are a fixed number of serialization formats (currently there are three,) each with fixed rules about how data is serialized and later de-serialized.
the benefit of this system is if you specify your abstract type system used to store or transmit data, and you make the serialization rules easy to implement, future programming languages, environments and operating systems should have minimal problems parsing the data.
LLSD for the impatient
the LLSD abstract type system defines 11 types: undefined, boolean, integer, real, string, date, URI, UUID, binary, array and map. The last two are "collections" meaning they're... well... they're collections of other types. arrays are (as you might have guessed) collections indexed by position while maps are indexed by keys. the undefined type is present to represent situations where the existence of an item is implied, but there's not enough information to assign a type to a data element. an example of when you attempt to retrieve an array or map element that doesn't exist. instead of getting an error, you get an undefined.
LLSD defines conversions between types that your implementing language should support. type conversions will get more important later when we talk about the LLIDL interface description language and programming styles that support loosely coupled systems. but for now just know that if you really want to convert the type of a data element, that's fine. but LLSD has a few rules about the conversion.
LLSD also defined default values for each type. defaults surface when you make an illegal type conversion. so if you convert a date to a boolean, you'll get the boolean default value (false.) if you convert an undefined value into any other type, you get the default value for that type. so if you attempted to read past the end of an array and cast that value as an integer, you would get 0, the default integer.
LLSD has three serialization schemes: XML, JSON and Binary. Each scheme is, in theory, no better than the other, but they were each designed for slightly different use cases. The XML serialization scheme is useful for environments that already use XML for other reasons. JSON is useful for web services and the Binary serialization scheme is useful for systems that need low message processing overhead.
better examples of serialized LLSD data can be found in the internet draft referenced above. but here is a very simple example of a map with three members: an integer, a string and an array:
<llsd>
<map>
<key>name</key>
<string>Zocalo Merchants</string>
<key>priority</key>
<int>12</int>
<key>position</key>
<array>
<int>128</int>
<int>192</int>
<int>20</int>
</array>
</map>
</llsd>
maddening weirdness can be your friend
there has been some criticism of LLSD's behavior regarding undefined type conversions and what to do when accessing a non-existent collection element. there are some very good arguments in favor of raising an exception. the primary benefit is that if there's an error involving type conversion weirdness, developers are more likely to catch it if the system signals an exception rather than "fails silently."
but there are two arguments against raising an execption. first, it's more complicated and requires that error handling be added to the abstract type system. secondly, it may lead to redundant error checking and brittle systems.
the argument goes something like this: "if i'm writing a service consuming an LLSD message, i'm probably going to be checking values at the application layer to make sure they make sense. if i'm checking them there, why do i need the presentation layer to check that they make sense?"
this argument implies that erroring out when you find an "illegal" type conversion doesn't really buy you anything, and you would have to complicate the specification to support it.
conclusion
so that's it. LLSD is a pretty small specification. there are already several oepn source implementations for the curious, and the most recent specification is available at the ietf.org web site. please take a look at it and give us feedback on the vwrap mailing list.
Thursday, April 15, 2010
Tuesday, April 13, 2010
VWRAP essentials : what's in the protocol?
it's no secret that VWRAP is heavily influenced by Second Life™'s next generation OGP protocol. (one view of how the OGP effort became the VWRAP working group can be found in "notes on the history of the VWRAP working group.") so it's not surprising that many people believe that every feature of Second Life™ will be found in the VWRAP protocol suite.
but this isn't the case; there will be many features of Linden's virtual world that won't be found in VWRAP. in this post, we're going to look at the VWRAP charter, a recent presentation by josh bell [PDF], and talk about why it's not a big deal some things are left out. but let's start with what's in and what's out.
what follows is a list of features that are widely believed to be "in" and "out." this is not an authoritative list; the feature list will only be official when the internet drafts describing VWRAP become RFCs. there's still time to influence the VWRAP protocol suite; join the vwrap@ietf.org mailing list and make your voice heard.
what's in : authentication and trust
the first step a client application should take when dealing with the virtual world is to authenticate themselves. in VWRAP the authentication process begins with the presentation of credentials and ends with the client application receiving a "seed capability" or "seed cap." you can find more information about this process in the "VWRAP Trust Model and User Authentication" draft.
the seed cap is a randomly generated, difficult to guess web address (URL.) when queried it returns information about where to find other services (like how to place your avatar in a region or manipulate your inventory.)
some members of the VWRAP mailing list have suggested that a virtual world open to anyone without authentication would be a productive use of the protocol. to support this use case, the authenticator in an authentication message is optional. which is to say, the protocol does not require an authenticator like a hashed password to accompany a login message, but the virtual world you connect to might.
it's also been pointed out that using Transport Layer Security (TLS) client certificates, OAuth or even HTTP authentication may be useful in some situations. so it may be more accurate to call the "authentication" phase more of an "identification with optional authentication" phase.
no matter what technique you use to successfully authenticate your client application to your authentication service, after it's over, the client has a seed capability and the authentication service has enough information to identify the client's user.
what's in : inventory, assets and basic permissions
developers should expect a "streamlined" asset system. there is a requirement to maintain positive copy control on objects for users who want such control. but the existing inventory / asset system used in Second Life™ is starting to show it's age.
assets in VWRAP will be represented as LLSD maps, retrieved using resources defined using the LLIDL interface description language, most likely over HTTP. an "asset" in VWRAP is a collection of meta-data and data. the "data" of an asset is tightly constrained by the asset's type: cubes are represented by cube data; textures with texture data; etc. asset meta-data will identify the creator, describe base permissions, and include textual descriptions of the object. assets will use URLs to reference other assets, and not UUIDs. for example, when a cube references a texture for each of it's faces, it will use URLs to point to the textures.
the SimianGrid project, which was born out of the Cable Beach Asset Server, has announced they will be participating in the development of the VWRAP inventory and asset system. Linden Research has not made a public statement of support of VWRAP inventory, but is expected to participate in it's development.
it should also be mentioned that regions could have region-specific assets. ground textures, the shape of buildings, etc. all might be stored in an asset server associated with the region and not with the user who created them.
what's in : spatial, user-to-user and group text and voice
text chat in Second Life™'s legacy protocol is mildly broken. spatial chat has reasonable performance, but uses the same protocol to carry text chat as to carry friend requests, inventory offers and such-like. group chat performance is much worse. its mostly the result of an arcane architecture involving routing chat messages though a simulator on the way to the user's viewer. simplification and performance enhancement is expected in both spatial and group text chat.
VWRAP will define a service for spatial, user-to-user and group text chat. there has been significant interest in using XMPP (or other established IM protocols) to carry text chat. this is a natural fit for user-to-user and group text chat.
voice is expected to work in radically the same way, but using SIP and RTP protocols instead of XMPP.
what's in : basic agent information
this does not mean "profile info." basic information would likely include very basic presence information like "this user is logged in" or "you can find this agent in this region." basic agent information is there to support other protocol functions (like teleportation and retrieving avatar shape info.)
what's in : teleport and region crossing
teleportation has changed radically from the Second Life™ legacy protocol. the biggest change is the idea that an agent's presence information can potentially be stored in two locations. OGP experimented with the idea that agent-oriented services should be segregated from simulation-oriented services. so if you wanted to know what region a user's avatar was rezzed in, you would query a service associated with that user, not with the region.
remember, in the OGP world, there may be several organizations that operate simulation regions. querying each of them to ask, "is this avatar located here?" is sub-optimal.
so this means that BOTH agent oriented services and region oriented services need to know where the user's avatar is. VWRAP is proposing extending the OGP Draft 5 Teleport specification to manage the intricate dance of moving an agent from one region to another.
what's in : avatar shape information
so we mentioned above that an agent's avatar will be available through the basic agent info service. it's unclear now what format avatar meshes will take. the existing Linden legacy format could be used. as could MPEG-V's ADML (avatar data markup language.) or maybe both.
whatever the format, a user's avatar will be made available to both client applications and simulation services.
what's in : the scene graph and object updates
when your avatar is rezzed into a region, the user's client application may pull a description of the scene graph. that is, the list of 3d objects observable in a given field of view.
there are several ways to communicate this information. for instance, the simulator could package up references to all items in the avatar's field of view and send it to the client as one large chunk. or it could just start sending a stream of messages; one message per object.
in the past, object update messages have been carried over raw UDP. in the future, object updates may be carried over RTP or an HTTP event queue.
what's in : object presence and physics simulation
objects in the virtual world persist. once they're rezzed, they should stay where they are until acted upon by an external force. "object presence" services will allow a client to query objects rezzed in the world for information like internal state, an object control channel (if you have rights to control it), etc.
objects that are subject to physical simulation may be moved or rotated by the simulation software running on the region they're rezzed in.
one of the fundamental features of VWRAP is that physics simulation happens centrally. that is, we don't do co-simulation where each client simulates physical interactions and then check with each other to see if any clients are out of sync.
what's in : region adjacency information
Second Life™ regions are rectangles, 256 meters on a side in the x and y dimension and stretching to infinity along the z axis. Second Life™ itself is a collection of these regions arranged in a grid. VWRAP will likely NOT mandate this shape as the standard for virtual worlds.
proposals have surfaced that describe the virtual world with spherical, cylindrical and toroidal coordinates. But even flat "grids" may have non-rectangular regions in the future. to help client applications figure out which systems to query for object information, a service is needed to describe the shape and partitioning of the virtual world.
this is not a map service per se, but something more fundamental. the virtual world is composed of multiple regions being stitched together to give the illusion of a seamless multi-dimensional space.
what's in : object and avatar control
a virtual world would be pretty boring if you couldn't move or animate your avatar. VWRAP will provide a simple, extensible protocol for sending control information to your avatar. the same protocol may be used to control other objects; think of virtual vehicles you climb in and drive.
what's out?
what's being left out of VWRAP is at least as interesting as what's going in. here's a rundown of major Second Life™ features you won't find in the spec.
what's out : game script
do not look for linden dollars in the VWRAP drafts; you won't find them. or at least you won't find them now. Linden expressed a preference that the linden dollar interface not be made part of the official specification. there are multiple reasons why this could be the case. VWRAP is still a technology under construction; a design flaw in VWRAP could lead to a very real vulnerability costing thousands if not millions of dollars. Linden also charges a fee for linden dollar transactions. it is possible they want to maintain control of the specification for purely mercantile reasons; to prevent VWRAP from letting third parties to wedge into the linden dollar exchange business.
some OpenSim developers expressed a desire to prevent Linden from encroaching on their turf. typical of their position is the statement, "why should i let Linden take a cut of my OpenSim based business?" the fear is that if a linden dollar API was included in the specifications, it would be considered mandatory. many OpenSim grid operators would not accept a mandatory linden dollar economy.
this is one of the most obvious places where business interest meets standards development, and it will be interesting to see what happens in the future. maybe Linden will open up a private VWRAP-like API for trusted partners. if you're an OpenSim operator not focused on eCommerce, this may be something you would be interested in. maybe third parties like two fish / live gamer will produce an alternative specification? it will certainly be interesting to watch the market develop.
what's out : land ownership
before i start any rumors, i should say that Linden is NOT going to eliminate private land ownership on it's grid. land ownership is not part of the VWRAP protocol suite because it's expected that different virtual worlds will manage land ownership differently.
VWRAP clients are expected to be able to query a region for "information about the place my user's avatar is at right now" and get a URL to a human readable, HTML web page. if the region supports land ownership, the web page will list that info. but the land ownership schema from Second Life™ will not be forced on all VWRAP virtual worlds.
this may be an issue for viewer developers. different protocols for land management will require client developers to know how to query a region for information about if and how ownership is represented and how to present it to the user.
what's out : building
so far there's been no mention of building as a use case for VWRAP. this doesn't mean it won't be supported, but it may be that building is handled by way of the generic object and avatar control protocol.
what's out : media attached to prims
Second Life™ has had "parcel media" for a while and recently added the ability to add media to a prim face. to date, this use case hasn't been discussed at length in the VWRAP working group. this is not to say it's not important, but it may be that the participants are happy to develop this standard later; perhaps after seeing what happens with Linden's "media on a prim" feature.
what's out : detailed avatar and user profiles
Second Life™ users are likely familiar with the standard user profile. imagine the ability to extend your profile to include information YOU think is important. this is what we're hoping to achieve by moving the profile information out of the core protocol and rebuild it as a simple web application. in the future, expect seeing a HTML page with protocol information instead of a fixed "floater" window in your favorite viewer. about the only thing the core protocol will specify is how to find the URL to the HTML profile page.
it sounds scary. but trust me; it'll be better.
why the sky not falling
some Second Life™ users may have an uneasy feeling, hearing that important features like game script, building and profile management WON'T be in the VWRAP protocol.
don't panic.
just because a feature is not in the VWRAP specification, it doesn't mean that feature will disappear from Second Life™ or any other virtual world. what it means is that Linden and the OpenSim developers may diverge on how they want to implement those features.
the lack of a feature in the specification means only that the participants could not find consensus on the feature's functionality. VWRAP will be complete enough to provide a rich experience. by agreeing to core functionality, it frees us to experiment with solutions for other, high-margin features.
it will, however, make client application coder's lives a little more complicated. where Second Life™ and OpenSimulator diverge, viewer developers will have to know how to work with both systems. this isn't as bad as it might seem; Linden's stock viewer already uses well known techniques to cope with protocol divergence. but more on that later...
in conclusion, let me encourage readers to subscribe to the vwrap mailing list where these specifications are being discussed. what to leave in and what to take out will certainly be the subject of continuing discussions. if you don't speak up now, you don't get to complain later.
but this isn't the case; there will be many features of Linden's virtual world that won't be found in VWRAP. in this post, we're going to look at the VWRAP charter, a recent presentation by josh bell [PDF], and talk about why it's not a big deal some things are left out. but let's start with what's in and what's out.
what follows is a list of features that are widely believed to be "in" and "out." this is not an authoritative list; the feature list will only be official when the internet drafts describing VWRAP become RFCs. there's still time to influence the VWRAP protocol suite; join the vwrap@ietf.org mailing list and make your voice heard.
what's in : authentication and trust
the first step a client application should take when dealing with the virtual world is to authenticate themselves. in VWRAP the authentication process begins with the presentation of credentials and ends with the client application receiving a "seed capability" or "seed cap." you can find more information about this process in the "VWRAP Trust Model and User Authentication" draft.
the seed cap is a randomly generated, difficult to guess web address (URL.) when queried it returns information about where to find other services (like how to place your avatar in a region or manipulate your inventory.)
some members of the VWRAP mailing list have suggested that a virtual world open to anyone without authentication would be a productive use of the protocol. to support this use case, the authenticator in an authentication message is optional. which is to say, the protocol does not require an authenticator like a hashed password to accompany a login message, but the virtual world you connect to might.
it's also been pointed out that using Transport Layer Security (TLS) client certificates, OAuth or even HTTP authentication may be useful in some situations. so it may be more accurate to call the "authentication" phase more of an "identification with optional authentication" phase.
no matter what technique you use to successfully authenticate your client application to your authentication service, after it's over, the client has a seed capability and the authentication service has enough information to identify the client's user.
what's in : inventory, assets and basic permissions
developers should expect a "streamlined" asset system. there is a requirement to maintain positive copy control on objects for users who want such control. but the existing inventory / asset system used in Second Life™ is starting to show it's age.
assets in VWRAP will be represented as LLSD maps, retrieved using resources defined using the LLIDL interface description language, most likely over HTTP. an "asset" in VWRAP is a collection of meta-data and data. the "data" of an asset is tightly constrained by the asset's type: cubes are represented by cube data; textures with texture data; etc. asset meta-data will identify the creator, describe base permissions, and include textual descriptions of the object. assets will use URLs to reference other assets, and not UUIDs. for example, when a cube references a texture for each of it's faces, it will use URLs to point to the textures.
the SimianGrid project, which was born out of the Cable Beach Asset Server, has announced they will be participating in the development of the VWRAP inventory and asset system. Linden Research has not made a public statement of support of VWRAP inventory, but is expected to participate in it's development.
it should also be mentioned that regions could have region-specific assets. ground textures, the shape of buildings, etc. all might be stored in an asset server associated with the region and not with the user who created them.
what's in : spatial, user-to-user and group text and voice
text chat in Second Life™'s legacy protocol is mildly broken. spatial chat has reasonable performance, but uses the same protocol to carry text chat as to carry friend requests, inventory offers and such-like. group chat performance is much worse. its mostly the result of an arcane architecture involving routing chat messages though a simulator on the way to the user's viewer. simplification and performance enhancement is expected in both spatial and group text chat.
VWRAP will define a service for spatial, user-to-user and group text chat. there has been significant interest in using XMPP (or other established IM protocols) to carry text chat. this is a natural fit for user-to-user and group text chat.
voice is expected to work in radically the same way, but using SIP and RTP protocols instead of XMPP.
what's in : basic agent information
this does not mean "profile info." basic information would likely include very basic presence information like "this user is logged in" or "you can find this agent in this region." basic agent information is there to support other protocol functions (like teleportation and retrieving avatar shape info.)
what's in : teleport and region crossing
teleportation has changed radically from the Second Life™ legacy protocol. the biggest change is the idea that an agent's presence information can potentially be stored in two locations. OGP experimented with the idea that agent-oriented services should be segregated from simulation-oriented services. so if you wanted to know what region a user's avatar was rezzed in, you would query a service associated with that user, not with the region.
remember, in the OGP world, there may be several organizations that operate simulation regions. querying each of them to ask, "is this avatar located here?" is sub-optimal.
so this means that BOTH agent oriented services and region oriented services need to know where the user's avatar is. VWRAP is proposing extending the OGP Draft 5 Teleport specification to manage the intricate dance of moving an agent from one region to another.
what's in : avatar shape information
so we mentioned above that an agent's avatar will be available through the basic agent info service. it's unclear now what format avatar meshes will take. the existing Linden legacy format could be used. as could MPEG-V's ADML (avatar data markup language.) or maybe both.
whatever the format, a user's avatar will be made available to both client applications and simulation services.
what's in : the scene graph and object updates
when your avatar is rezzed into a region, the user's client application may pull a description of the scene graph. that is, the list of 3d objects observable in a given field of view.
there are several ways to communicate this information. for instance, the simulator could package up references to all items in the avatar's field of view and send it to the client as one large chunk. or it could just start sending a stream of messages; one message per object.
in the past, object update messages have been carried over raw UDP. in the future, object updates may be carried over RTP or an HTTP event queue.
what's in : object presence and physics simulation
objects in the virtual world persist. once they're rezzed, they should stay where they are until acted upon by an external force. "object presence" services will allow a client to query objects rezzed in the world for information like internal state, an object control channel (if you have rights to control it), etc.
objects that are subject to physical simulation may be moved or rotated by the simulation software running on the region they're rezzed in.
one of the fundamental features of VWRAP is that physics simulation happens centrally. that is, we don't do co-simulation where each client simulates physical interactions and then check with each other to see if any clients are out of sync.
what's in : region adjacency information
Second Life™ regions are rectangles, 256 meters on a side in the x and y dimension and stretching to infinity along the z axis. Second Life™ itself is a collection of these regions arranged in a grid. VWRAP will likely NOT mandate this shape as the standard for virtual worlds.
proposals have surfaced that describe the virtual world with spherical, cylindrical and toroidal coordinates. But even flat "grids" may have non-rectangular regions in the future. to help client applications figure out which systems to query for object information, a service is needed to describe the shape and partitioning of the virtual world.
this is not a map service per se, but something more fundamental. the virtual world is composed of multiple regions being stitched together to give the illusion of a seamless multi-dimensional space.
what's in : object and avatar control
a virtual world would be pretty boring if you couldn't move or animate your avatar. VWRAP will provide a simple, extensible protocol for sending control information to your avatar. the same protocol may be used to control other objects; think of virtual vehicles you climb in and drive.
what's out?
what's being left out of VWRAP is at least as interesting as what's going in. here's a rundown of major Second Life™ features you won't find in the spec.
what's out : game script
do not look for linden dollars in the VWRAP drafts; you won't find them. or at least you won't find them now. Linden expressed a preference that the linden dollar interface not be made part of the official specification. there are multiple reasons why this could be the case. VWRAP is still a technology under construction; a design flaw in VWRAP could lead to a very real vulnerability costing thousands if not millions of dollars. Linden also charges a fee for linden dollar transactions. it is possible they want to maintain control of the specification for purely mercantile reasons; to prevent VWRAP from letting third parties to wedge into the linden dollar exchange business.
some OpenSim developers expressed a desire to prevent Linden from encroaching on their turf. typical of their position is the statement, "why should i let Linden take a cut of my OpenSim based business?" the fear is that if a linden dollar API was included in the specifications, it would be considered mandatory. many OpenSim grid operators would not accept a mandatory linden dollar economy.
this is one of the most obvious places where business interest meets standards development, and it will be interesting to see what happens in the future. maybe Linden will open up a private VWRAP-like API for trusted partners. if you're an OpenSim operator not focused on eCommerce, this may be something you would be interested in. maybe third parties like two fish / live gamer will produce an alternative specification? it will certainly be interesting to watch the market develop.
what's out : land ownership
before i start any rumors, i should say that Linden is NOT going to eliminate private land ownership on it's grid. land ownership is not part of the VWRAP protocol suite because it's expected that different virtual worlds will manage land ownership differently.
VWRAP clients are expected to be able to query a region for "information about the place my user's avatar is at right now" and get a URL to a human readable, HTML web page. if the region supports land ownership, the web page will list that info. but the land ownership schema from Second Life™ will not be forced on all VWRAP virtual worlds.
this may be an issue for viewer developers. different protocols for land management will require client developers to know how to query a region for information about if and how ownership is represented and how to present it to the user.
what's out : building
so far there's been no mention of building as a use case for VWRAP. this doesn't mean it won't be supported, but it may be that building is handled by way of the generic object and avatar control protocol.
what's out : media attached to prims
Second Life™ has had "parcel media" for a while and recently added the ability to add media to a prim face. to date, this use case hasn't been discussed at length in the VWRAP working group. this is not to say it's not important, but it may be that the participants are happy to develop this standard later; perhaps after seeing what happens with Linden's "media on a prim" feature.
what's out : detailed avatar and user profiles
Second Life™ users are likely familiar with the standard user profile. imagine the ability to extend your profile to include information YOU think is important. this is what we're hoping to achieve by moving the profile information out of the core protocol and rebuild it as a simple web application. in the future, expect seeing a HTML page with protocol information instead of a fixed "floater" window in your favorite viewer. about the only thing the core protocol will specify is how to find the URL to the HTML profile page.
it sounds scary. but trust me; it'll be better.
why the sky not falling
some Second Life™ users may have an uneasy feeling, hearing that important features like game script, building and profile management WON'T be in the VWRAP protocol.
don't panic.
just because a feature is not in the VWRAP specification, it doesn't mean that feature will disappear from Second Life™ or any other virtual world. what it means is that Linden and the OpenSim developers may diverge on how they want to implement those features.
the lack of a feature in the specification means only that the participants could not find consensus on the feature's functionality. VWRAP will be complete enough to provide a rich experience. by agreeing to core functionality, it frees us to experiment with solutions for other, high-margin features.
it will, however, make client application coder's lives a little more complicated. where Second Life™ and OpenSimulator diverge, viewer developers will have to know how to work with both systems. this isn't as bad as it might seem; Linden's stock viewer already uses well known techniques to cope with protocol divergence. but more on that later...
in conclusion, let me encourage readers to subscribe to the vwrap mailing list where these specifications are being discussed. what to leave in and what to take out will certainly be the subject of continuing discussions. if you don't speak up now, you don't get to complain later.
Monday, April 12, 2010
VWRAP essentials : what does it mean to be "Second Lifelike" ?
so the VWRAP working group is off to a good start. we've completed the chartering process and published a few internet drafts. we also had a face-to-face meeting a couple weeks ago that identified a couple defects in some of our draft documents.
now it's time to start recruiting people to help with the effort. the documents we produce will require a number of participants documenting use cases, writing documents, creating sample code implementations, checking the technical contents of draft documents and reviewing the group's output to make sure it just plain makes sense.
but every time i ask someone to help out, they want to read our background documents. and this is where i start getting kind of embarrassed. we don't have nearly as many as we need. so i'm writing a series of blog posts about it to give an informal and informational introduction to VWRAP, the Virtual World Region Agent Protocol.
if you're new to VWRAP, you may want to read the "what's VWRAP.". for more detailed info, you may want to read the "VWRAP : Introduction and Goals" document. the current draft is 32 pages and is written to be as precise as possible. because it was written with "correctness" in mind, it can be a bit wordy at times. so my first couple blog posts will be high level discussions about what we're trying to accomplish.
several people have used the term "Second Lifelike" to describe the type of virtual world we're hoping to create. but that's a little bit of a fail; it's bad form to describe something new by saying "hey, it's just like this other thing, only a little different." so maybe the first question to ask is...
what does it mean to be second lifelike ?
if you've visited Second Life(tm) as a user and then visited World of Warcraft(tm) or EVE Online(tm), you know they're each pretty different experiences. WoW is mostly about fighting. sure, you can be social in some corners of the world, but what you're paying for is the ability to reign down hurt on other players. EVE Online is about dueling spaceships while Second Life is about capturing the experience of burning man by socializing and building interesting bits of art. or maybe its about business and education; we're still trying to figure that one out. but it's clearly more open ended than other popular massively multi-participant systems.
but for software developers and virtual world deployers, it's probably a good idea to have a better description of the protocol than "oh, it's sorta like Second Life(tm) or OpenSim." in the "intro and goals" document referenced above, there are three primary features of VWRAP virtual worlds:
the virtual world exists independently of the participants
some readers will remember VRML (Virtual Reality Markup Language.) it was a text based language for describing virtual world scene graphs. there was an interactivity model for VRML, so you could get objects to do things by interacting with the virtual environment. but for the most part, tools that used VRML rendered scene graphs on local systems and did not interact with remote systems or users.
so you loaded a virtual experience from local storage or from the web, rendered the scene, twirled around to look at the objects and could optionally interact with this "pocket universe."
some of the tools seemed advanced (even for today) and you could mock up some relatively interesting scenes. but, at the end of the day, there were no standards for how to invite other participants into your virtual creation.
this is NOT what VWRAP is all about. VWRAP is about multiple individuals accessing the same scene graph hosted on a public server somewhere and everyone sees the same thing when they log in. VWRAP worlds are inherently shared experiences, not pocket universes on someone's desktop system.
avatars have a single, unique presence in a single virtual world
like the reified world, the virtual world is a social space. the locus of social activity in the virtual world is the user's avatar; each avatar representing a single user. with due respect to even the best "real world" multi-taskers, you can still only be in one place at a time. so it is with avatars in the virtual world.
it also means that for every different virtual world, there is only one of you. by default, you can interact with everyone else in the world and they can interact with you.
the virtual world contains persistent objects
objects in the virtual world, like virtual worlds themselves, persist beyond a user's presence in the virtual world. if a user created a desk and chairs in a VWRAP virtual world, it would continue to exist until explicitly deleted. so the user could log in, create an object in a particular location in the virtual world and then log out. when another user logs in and travels to the same location, they would see that object.
the "intro and goals" draft referenced above describes these characteristics in more detail, but the text here describes the basics of VWRAP virtual worlds: there's only one of you, there's stuff in the world and the world doesn't disappear when you turn your back.
now it's time to start recruiting people to help with the effort. the documents we produce will require a number of participants documenting use cases, writing documents, creating sample code implementations, checking the technical contents of draft documents and reviewing the group's output to make sure it just plain makes sense.
but every time i ask someone to help out, they want to read our background documents. and this is where i start getting kind of embarrassed. we don't have nearly as many as we need. so i'm writing a series of blog posts about it to give an informal and informational introduction to VWRAP, the Virtual World Region Agent Protocol.
if you're new to VWRAP, you may want to read the "what's VWRAP.". for more detailed info, you may want to read the "VWRAP : Introduction and Goals" document. the current draft is 32 pages and is written to be as precise as possible. because it was written with "correctness" in mind, it can be a bit wordy at times. so my first couple blog posts will be high level discussions about what we're trying to accomplish.
several people have used the term "Second Lifelike" to describe the type of virtual world we're hoping to create. but that's a little bit of a fail; it's bad form to describe something new by saying "hey, it's just like this other thing, only a little different." so maybe the first question to ask is...
what does it mean to be second lifelike ?
if you've visited Second Life(tm) as a user and then visited World of Warcraft(tm) or EVE Online(tm), you know they're each pretty different experiences. WoW is mostly about fighting. sure, you can be social in some corners of the world, but what you're paying for is the ability to reign down hurt on other players. EVE Online is about dueling spaceships while Second Life is about capturing the experience of burning man by socializing and building interesting bits of art. or maybe its about business and education; we're still trying to figure that one out. but it's clearly more open ended than other popular massively multi-participant systems.
but for software developers and virtual world deployers, it's probably a good idea to have a better description of the protocol than "oh, it's sorta like Second Life(tm) or OpenSim." in the "intro and goals" document referenced above, there are three primary features of VWRAP virtual worlds:
- the virtual world exists independently of the participants,
- avatars have a single, unique presence in a single virtual world, and,
- the virtual world contains persistent objects.
the virtual world exists independently of the participants
some readers will remember VRML (Virtual Reality Markup Language.) it was a text based language for describing virtual world scene graphs. there was an interactivity model for VRML, so you could get objects to do things by interacting with the virtual environment. but for the most part, tools that used VRML rendered scene graphs on local systems and did not interact with remote systems or users.
so you loaded a virtual experience from local storage or from the web, rendered the scene, twirled around to look at the objects and could optionally interact with this "pocket universe."
some of the tools seemed advanced (even for today) and you could mock up some relatively interesting scenes. but, at the end of the day, there were no standards for how to invite other participants into your virtual creation.
this is NOT what VWRAP is all about. VWRAP is about multiple individuals accessing the same scene graph hosted on a public server somewhere and everyone sees the same thing when they log in. VWRAP worlds are inherently shared experiences, not pocket universes on someone's desktop system.
avatars have a single, unique presence in a single virtual world
like the reified world, the virtual world is a social space. the locus of social activity in the virtual world is the user's avatar; each avatar representing a single user. with due respect to even the best "real world" multi-taskers, you can still only be in one place at a time. so it is with avatars in the virtual world.
it also means that for every different virtual world, there is only one of you. by default, you can interact with everyone else in the world and they can interact with you.
the virtual world contains persistent objects
objects in the virtual world, like virtual worlds themselves, persist beyond a user's presence in the virtual world. if a user created a desk and chairs in a VWRAP virtual world, it would continue to exist until explicitly deleted. so the user could log in, create an object in a particular location in the virtual world and then log out. when another user logs in and travels to the same location, they would see that object.
the "intro and goals" draft referenced above describes these characteristics in more detail, but the text here describes the basics of VWRAP virtual worlds: there's only one of you, there's stuff in the world and the world doesn't disappear when you turn your back.
Wednesday, April 7, 2010
notes on the history of the VWRAP working group
after my last post about VWRAP, a couple people pinged me asking about it's history. here is a quick narrative of how VWRAP came to be and where it might be headed next.
the effort to establish the VWRAP working group has been ongoing for about a year, and it has a surprisingly rich history for an effort that's been ongoing for that short of a period of time. our group is certainly not the first attempt to develop interoperable virtual worlds standards; that's been going on for quite a while.
VWRAP recent history begins with an interoperability test sponsored by IBM and Linden Lab in the summer of 2008. using ideas that had been discussed in the Second Life(tm) architecture working group, several users were able to teleport their avatars from Linden-owned to systems owned by third parties.
there were significant limitations however. avatar appearance was inconsistent across regions and cross-grid access to inventory was more or less nonexistent. but as a first step, it showed that cross-grid teleports were possible.
VWRAP recent history begins with an interoperability test sponsored by IBM and Linden Lab in the summer of 2008. using ideas that had been discussed in the Second Life(tm) architecture working group, several users were able to teleport their avatars from Linden-owned to systems owned by third parties.
there were significant limitations however. avatar appearance was inconsistent across regions and cross-grid access to inventory was more or less nonexistent. but as a first step, it showed that cross-grid teleports were possible.
interested users can find documentation of the protocol used by these early interop trials on the Second Life(tm) wiki:
later that year we entered a time of economic uncertainty. virtual world interoperability did not seem to contribute to the bottom line, and there were significant near-term opportunity costs. "let's type up a report on our experiences, publish our final OGP drafts and focus on less risky things for a few months before coming back to it." we were in the process of mothballing the interop effort when things took an interesting turn.
inside the lab, we knew the UDP-based legacy SL protocol had some serious scalability problems; we wanted to move more services to LLSD over HTTP. most of our work serialized LLSD messages as XML documents and sent them over the internet. as part of our "wrapping up" process, we figured we should register the MIME types we used for LLSD. this was the motivation for the original "LLSD Abstract Type System" draft published in early 2009.
at around this same time, the bidirectional http effort inside the IETF was heating up and mark lentczner was asked to submit a draft and a presentation on "Reverse HTTP" which was based on previous work at the lab with donovan preston.
originally intended to be small, stand-alone drafts with a limited scope, we began the task of publishing an informational RFC for the purpose of registering the LLSD MIME types.
starting a virtual worlds working group in the IETF was not a new idea. the SWMP mailing list had been setup in 2007 to discuss the idea. it eventually failed to result in a working group for reasons that are too complicated to discuss here. there was considerable resistance to the idea, but around this time, david lavine at IBM started asking "what's next with interop?" david and suzy deffeyes had invested a fair amount of effort in the 2008 interop trail, so it was a reasonable question.
the more we talked about it, the more it seemed like a good idea. in early 2009, mark lentczner and i lobbied inside the lab for the idea while david and suzy pushed the idea inside IBM. the IETF does not officially recognize corporate members, people who show up at IETF meetings represent themselves. but if a working group was ever to be formed, but none of us felt comfortable pushing the idea without the support of our management.
we eventually produced an argument for interop good enough to garner support inside IBM and linden, so in january of 2009, david lavine of IBM and i approached the IETF informally with a proposal to sponsor the work of developing a virtual worlds interoperability prototype. at the time, we had hoped to develop a protocol that would work for a broad range of virtual experiences.
IETF process calls for a "Birds of a Feather" or BoF meeting to be held to see if there is sufficient interest to justify creation of an official working group. on march 24th, 2009 the "MMOX BoF" was held at the 74th IETF meeting in San Francisco, CA.
inside the lab, we knew the UDP-based legacy SL protocol had some serious scalability problems; we wanted to move more services to LLSD over HTTP. most of our work serialized LLSD messages as XML documents and sent them over the internet. as part of our "wrapping up" process, we figured we should register the MIME types we used for LLSD. this was the motivation for the original "LLSD Abstract Type System" draft published in early 2009.
at around this same time, the bidirectional http effort inside the IETF was heating up and mark lentczner was asked to submit a draft and a presentation on "Reverse HTTP" which was based on previous work at the lab with donovan preston.
originally intended to be small, stand-alone drafts with a limited scope, we began the task of publishing an informational RFC for the purpose of registering the LLSD MIME types.
starting a virtual worlds working group in the IETF was not a new idea. the SWMP mailing list had been setup in 2007 to discuss the idea. it eventually failed to result in a working group for reasons that are too complicated to discuss here. there was considerable resistance to the idea, but around this time, david lavine at IBM started asking "what's next with interop?" david and suzy deffeyes had invested a fair amount of effort in the 2008 interop trail, so it was a reasonable question.
the more we talked about it, the more it seemed like a good idea. in early 2009, mark lentczner and i lobbied inside the lab for the idea while david and suzy pushed the idea inside IBM. the IETF does not officially recognize corporate members, people who show up at IETF meetings represent themselves. but if a working group was ever to be formed, but none of us felt comfortable pushing the idea without the support of our management.
we eventually produced an argument for interop good enough to garner support inside IBM and linden, so in january of 2009, david lavine of IBM and i approached the IETF informally with a proposal to sponsor the work of developing a virtual worlds interoperability prototype. at the time, we had hoped to develop a protocol that would work for a broad range of virtual experiences.
IETF process calls for a "Birds of a Feather" or BoF meeting to be held to see if there is sufficient interest to justify creation of an official working group. on march 24th, 2009 the "MMOX BoF" was held at the 74th IETF meeting in San Francisco, CA.
it did not go as well as we had hoped, but it didn't go as bad as we feared it could.
we were unable to reach consensus for "broad interoperability." we would not be able to, as david lavine once hoped, "meet with your raiding party in the sims online, teleport over to world of warcraft(tm), slay a dragon and then teleport to a pub in Second Life(tm) to celebrate."
but we did discover that there were enough people at Linden Lab and in the OpenSimulator community that were interested in cross-world interoperability. the IETF allowed us to redefine our scope and hold a second BoF session. on july 28th, 2009, the "OGPX BoF" was held to discuss the scope of the work (OGPX standing for "Open Grid Protocol X".) this meeting went well and following some discussion on the ogpx@ietf.org mailing list, we were able to agree to a group charter.
in the IETF, a working group charter defines what the group is supposed to be working on and what documents it proposes to produce. you can view the current charter for the group at http://www.ietf.org/dyn/wg/charter/vwrap-charter . along the way, a number of people objected to the name "OGP" or "Open Grid Protocol" as they felt it implied the objective of the protocol was to manage cloud or grid based systems. many alternate names were proposed (including my favorites Open Virtual EnviRonments (OVER) and Agent BackbOne for Virtual Environments (ABOVE).)
eventually settled on the name "VWRAP: Virtual Worlds Region Agent Protocol."
eventually settled on the name "VWRAP: Virtual Worlds Region Agent Protocol."
as an aside, after changing the name from OGPX to VWRAP, we forgot to change the name of the mailing list until very recently. the current mailing list is vwrap@ietf.org, though there has been significant discussion on ogpx@ieft.org and mmox@ietf.org.
on march 23rd, 2010, the working group held it's first official face to face meeting in Anaheim, California. it was a mixed reality event with approximately 15-20 people being present in incarnate reality and 50 avatars attending in the virtual world.
the work continues on the vwrap mailing list, and anyone with an interest in virtual worlds interoperability is encouraged to participate.
on march 23rd, 2010, the working group held it's first official face to face meeting in Anaheim, California. it was a mixed reality event with approximately 15-20 people being present in incarnate reality and 50 avatars attending in the virtual world.
the work continues on the vwrap mailing list, and anyone with an interest in virtual worlds interoperability is encouraged to participate.
Friday, April 2, 2010
did i forget to mention? you can hire me.
As some people are aware, I left Linden Research in February of this year. I had intended to join a startup in the bay area. but when that plan fell through, I started taking on short term contracts to pay the bills 'til something more permanent came along. As it turns out, there seems to be a lot of contracting work out there, so I'll probably stay a consultant for the near term.
However, some contracting opportunities match my background better than others. So I figured I would take a moment to mention I'm a seasoned software engineering professional with experience as an engineering manager, software architect and software developer. I am a subject matter expert on virtual worlds, mobile hardware development and implementing Public Key Infrastructures and their related cryptographic algorithms. I am an able communicator, having presented at conferences and written internet drafts, software documentation and technology white papers.
If you are looking for a software developer or agile development leader, look at my LinkedIn profile for an example of some projects I've been involved with or drop me a line at OhMeadhbh@gmail.com.
what's the Virtual World Region Agent Protocol ?
i recently had the pleasure of talking with Maria Korolov at HypergridBusiness.Com. she was interested in understanding the differences between Hypergrid and VWRAP. (who knows, maybe there will be a story about it in the near future?) but this sort of got me thinking, there are very few places an interested non-specialist can go to learn about VWRAP, it's goals and approach to virtual worlds. this blog post is an effort to fill that gap.
what is VWRAP?
the Virtual World Region Agent Protocol (aka VWRAP) is an application layer wire protocol used to create "interoperable virtual experiences." it is also the name of the working group inside the Internet Engineering Task Force (IETF) developing the protocol.
okay... so that's a mouthful; let's break it down.
a "wire protocol" is a set of conventions and standards describing data flowing over a network. HTTP for instance, or SMTP are both wire protocols; they describe the format of messages web browsers or email clients generate. a protocol doesn't equal an implementation. the apache web server, for instance, implements the HTTP protocol, but does not define it. so it is with VWRAP virtual worlds: the protocol lists what data is exchanged in between systems cooperating to "create" the virtual world. VWRAP is expected to be implemented by server software at Linden Lab, the OpenSimulator project and SimianGrid (formerly Cable Beach.)
we say that it's an "application layer protocol" because it makes use of familiar net protocols for moving information around. that is, VWRAP messages are carried by HTTP and (possibly) RTP, the protocols responsible for the web and VoIP.
and what's an "interoperable virtual experience?" this just means that virtual world viewers can use VWRAP protocols to simulate a virtual world shared by multiple participants. i like to say "virtual experiences" these days as i've been involved in some pretty heated debates as to what the term "virtual world" means.
so VWRAP is a protocol and a community of people working to build systems that let users have a "Second Lifelike" experience, but in an "open" virtual world. that is, you can have an experience that looks like second life, but does not require your virtual locations or virtual belongings to be hosted by machines owned by Linden Lab.
why is VWRAP not like Hypergrid or OpenWonderland or Croquet or ... ?
there are several virtual worlds out there ranging from the game-like World of Warcraft(tm) to the open-ended Second Life(tm). Some are open source projects like Croquet, RealXtend, OpenWonderland or OpenSimulator. Others are commercial services like ReactionGrid or cooperatives like OSGrid.
VWRAP is not an implementation or (like Hypergrid) an extension to an existing implementation. it is an open protocol, developed by a community of interested parties with the intent that anyone can choose to implement it. so VWRAP will not be a new product, but likely a new feature to existing implementations and services that will make it easier for them to communicate with each other. (though there are sure to be "sample implementations" of the VWRAP specifications.)
VWRAP is "Second Lifelike" in that it assumes a virtual world somewhat like Second Life(tm) or one created with OpenSimulator. World of Warcraft(tm), Croquet and OpenWonderland use protocols that are significantly different from the ones for Second Lifelike worlds. and the way they think avatars will interact is a little different. it's not impossible for these systems to use VWRAP, but they're not what VWRAP was intended to support. (though there may be ways for these systems to use pieces of VWRAP. more on this later.)
another important feature about VWRAP: some people will consider it incomplete. the people behind VWRAP chose to NOT standardize certain features of virtual worlds. VWRAP does not include standards relating to ecommerce or "game script" like linden dollars. nor does it describe standards for virtual land ownership like Second Life's parcels and estates.
it does, however, make it easy to define new services and to extend existing services. so it should be pretty easy to extend Linden Lab's Snowglobe viewer (and other open source viewers) to support different, world-specific ecommerce and land ownership features. so you may not get to use linden dollars on OSGrid, but if a region owner wants to support something else, it should be pretty easy for the viewer developers to code to it.
in other words, virtual worlds users should find the software they use get a little more robust and should see new features emerge a little faster.
so to recap: VWRAP is a set of protocols, not an implementation. VWRAP protocols are expected to not only be the basis for new products, but also to be added to existing systems as extensions.
what is the IETF and why is it important to this discussion?
the internet engineering task force (IETF) is a "standards development organization" which focuses on internet protocols. it is well known for being the professional forum where TCP/IP (a very popular networking technology) and SMTP (the standard email protocol) were developed. the IETF is not a commercial organization; it's more like a non-profit or NGO. it's stated goal is to improve people's lives by making network equipment and software work together.
an interesting feature of the IETF is that when protocols are developed under it's auspices, they're considered "open" and "public." that is, there is no charge to implement them. you don't have to sign non-disclosure agreements and you don't have to pay money to download them. membership in the working groups that define standards is open to the public; anyone can participate. when Linden and IBM approached the IETF saying they wanted to develop a "next generation" protocol as an IETF activity, they were explicitly agreeing to public commentary and participation in the process.
that being said, there are some intellectual property issues. specifically, there is a patent held by IBM that may or may not have bearing on the implementation of VWRAP services. the IETF process requires participants to disclose any known patents related to the work. this allows developers to decide if they want to participate or agree to make a standard that may be covered by software patents. in this case, IBM filed the requisite disclosure and has offered VWRAP developers a blanket license to use their intellectual property for the purpose of implementing the VWRAP standard(s). i am not a lawyer, however. you should get competent legal authority to verify what i just wrote.
how will we know if we've succeeded?
there's been a little confusion about what we're trying to do with VWRAP. we're not trying to compete with Hypergrid or Croquet or OpenWonderland. rather, we're trying to define the protocol for services that anyone could implement, even 2d web services.
we'll know we've succeeded when after publishing our specifications, users can log into virtual worlds using their twitter or wikimedia account credentials. or if they're able to use the wikimedia commons as an asset server. or if they can teleport between OSGrid and Second Life(tm).
how can you help?
the VWRAP working group is made up predominantly of implementers. that is, people who write software are disproportionately represented. we need more input from people who deploy virtual worlds and from people who live in them. most of the discussions will be highly technical in nature, and that might be intimidating to some.
but it is an open process; everyone is welcome to listen to the discussion. as long as you're not abusive to other list participants, you are welcome to post comments or questions. keep in mind that the answers may not be exactly what you want to hear, and questions should be focused on the technology (and not Linden or OSGrid policy.) but as technology developers, we need to know what your use cases are.
the mailing list for this group is vwrap@ietf.org . a good place to start is by reading the "intro and goals" internet draft.
i hope this answers a few questions about the VWRAP protocol and working group. feel free to email me at OhMeadhbh@gmail.com with questions.
Subscribe to:
Comments (Atom)