Re: [vwrap] Consensus? What exactly should be in the protocol

[Mike Dickson <[e-mail]>]

  An excellent synopsis.  It could make a great intro for a document 
describing what VWRAP is trying to do....

Mike

On 09/22/2010 01:39 PM, David W Levine wrote:
>
> So, of course we're building in the web space. I hope nobody is 
> denying that. In fact if you look at everything described in VWRAP is 
> starts with an assumption that most services are delivered as REST or 
> REST like services. I think its safe to say that the people who have 
> been discussing this for over two years are aware of Roy's work, and 
> have thought about how REST applies to virtual worlds. REST represents 
> a lot of thinking about how the web delivers content, and in 
> particular why not to turn the web into a
> distributed object model, or a shared state model, but rather to 
> leverage the observed successful patterns of the web in managing 
> distributed programming problems.
>
> But.. (There is always a but) The very core thing that a virtual world 
> does doesn't fit terribly well into the mainstream web model. The 
> heart of a virtual world is delivering (and Morgaine's phrase serves 
> very well here) a visual mashup of things to users 30-60 times a 
> second, updating continually to reflect the input of the physical 
> simulation, any user
> inputs, and any scripted inputs. Our core problem is taking in the 
> inputs, deriving the new state and sharing it out to the users. This 
> isn't really what the web has historically done. The fact that it 
> isn't, that there are some really interesting distributed system 
> challenges at the very heart of this, is part of its technical appeal 
> to me.
>
> Life is made harder by the fact that the virtual space is being 
> constantly asked to accept new things to deal with. Every time an 
> avatar arrives it brings a set of stuff
> which has to be melded into the scenegraph. Again, we all know this. 
> Rezing an avatar means adding a bunch of new content to the virtual 
> space, and it means pushing
> it back out to all the observers.
>
> In the traditional web you go to a URL, you do a get, and you get 
> handed a huge slab of stuff to render.(some of which may require 
> fetches, plugins, etc.) In the more dynamic 2.0 style stuff, the stuff 
> you get may include dynamic elements which fetch and update more 
> stuff. In the virtual worlds space, we bring to to a fever pitch. we 
> take inputs from all the present users, from a simulation, including 
> the scripted changes within the simulation. We then turn around and 
> want to show this to the user.
>
> How do we present this to the user. Well, we currently use Linden's 
> UDP/http/longpoll tangle. Fine. But. how could we do it?
>
> We could create a video stream and stream it. (WHich isn't very web 
> page like at all, but has some nice properties)
> We could do something like OnLive where we would create a very 
> tailored stream and deliver it to a client with very specialized 
> coupled inputs (And life with a lot of
> constraints and again isn't very web page like)
> We could send a stateless update every frame for the client to render 
> (Well, with ulimited bandwidth and processor power)
> Or.. we could do what we currently do, just cleaner. which, roughly 
> speaking is send down initial state and then send down a series of 
> updates to that state. Woah, not
> exactly a traditional web page. Worse still.. where do we post the 
> inputs from the client to the world?
>
> At the same time, we also get to ask "How do we get all the "stuff" 
> into the region. In Linden's world, the answer is easy. They use a 
> proprietary protocol and fetch it from
> their creaking central servers. In OpenSim, a similar answer obtains. 
> And for added pain which we have all shared, the current set of 
> clients push all the stuff related to
> the user via the region.
>
> VWRAP attempts to describe nothing more than a set of REST web 
> services which represent the region and the services. It attempts to 
> leverage what's been learned from REST, and Linden's system, and in 
> fact OpenSim, to describe a simple, extensible set of services which 
> can describe: Regions, Auth services, how to rez and unrez avatars, 
> how to (when we get some writing down) fetch and manipulate assets, 
> inventory lists and so on.
>
> What you end up with is built deeply on web principals, but not a web 
> page, but mostly because a virtual world is not, at its heart a web 
> page,but a set of services collaborating to
> share state in a pretty unusual way.
>
> - David
> ~Zha
>