Re: [ogpx] A blog post from the HTML5/Websocket wars worth reading

[Meadhbh Hamrick <[e-mail]>]

On Fri, Feb 19, 2010 at 6:12 AM, Carlo Wood <[e-mail]> wrote:

> Agreed. SL should be VWRAP compatible, but there is no need
> for another world that uses VWRAP to really be anything like SL.


well.. actually.. yes there is. (and yes, no there's not.)

people familiar with the history of VWRAP will remember that before VWRAP,
we had the MMOX BoF. MMOX was introduced with a "wide" charter. we wanted to
try to get as many participants as possible, and introduce compatibility
with as many existing systems as possible.

but guess what? it turned into an utter failure. the common ground between
Second Life, Wonderland, Olive, Webkins, et al. was just too small to
produce a meaningful specification.

at the end of the MMOX BoF, the suggestion was made that we have another
BoF, but with a more limited scope. that's where the OGPX BoF came from.
OGPX was an attempt to describe the "problem domain" that SL is the solution
for. a number of us thought long and hard about the social and technical
concerns SL addresses and were able to distill them into the charter and the
intro and goals document.

so we may want to be careful when we say things like "there is no need for
another world that uses VWRAP to really be anything like SL." it's
COMPLETELY true that there could be a lot of things that don't need to be
replicated. for instance, Second Life's use of the Linden game script or the
particular way in which property is represented in SL (parcel, simulator,
estate, etc.)

but if you want to have a chance of interoperability, there must be basic
constraints and processing expectations.

for example. 3d descriptions of assets (either as primitives, collections of
nurbs, sculpties or meshes) are intended to be rendered. there is a use case
that they be rendered as part of a 3d scene. yes, we may also have the use
case of rendering them as part of a web page. or converting them into a JPEG
and printing them on a mug at cafepress.com or ...

so yes. we should not place limitations on where an asset can be rendered.
but we should understand that the asset data for a 3d object is intended to
be rendered. it's not going to be used as the seed to a random number
generator whose output is used to make stock purchase decisions or rendered
as an audio stream. (well. sure. you could. but it SHOULDN'T be a supported
use case.)

so getting back to the description of "Second Life-Like" as a way to
describe VWRAP. this was actually the elevator pitch for OGPX... to
determine the specs for "Second Life-Like" worlds. at the time it was a
shorthand for describing how Second Life and OpenSimulator differed from
projects like Olive or Wonderland. moving forward, this moniker will likely
be both and impediment and a benefit. it's beneficial in that when someone
asks what we're trying to do, we could simply say... "we're making specs for
OpenSim-Like or SecondLife-Like worlds." but these descriptions carry
baggage.

so it's true to a certain degree that there are no requirements that a
virtual world that uses VWRAP look anything like Second Life(tm), Second
Life (tm) and OpenSim were the exemplars of the class from which our
requirements were drawn. so i think we'll see that "VWRAP worlds" will share
a lot of similarities. or not.

but my point is that the stated objective of this group is work on protocols
whose requirements and expected use are radically similar to that of SL and
OpenSim. we no longer use the ostensive definition of "it has to be like
Second Life(tm)." but if we produce a protocol that meets the requirements
set down in the charter, we'll likely find we have something that is similar
in many key respects to SL or OpenSim.

-cheers
-meadhbh