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

[Cristina Videira Lopes <[e-mail]>]

Meadhbh Hamrick wrote:
> On Wed, Sep 22, 2010 at 11:59 AM, Cristina Videira Lopes
> <[e-mail]> wrote:
>   
>> Cristina Videira Lopes wrote:
>>     
>>> You can dictate that. But then this will be completely irrelevant in a
>>> couple of years when WebGL is actually usable or when Google finishes their
>>> virtual machine for running safe native code on browsers.
>>>       
>> ...or when server-side streaming goes mainstream, and being in a virtual
>> world is as simple as running a video player plus a few JavaScript/native
>> back channels to the server.
>>
>> First point is: according to the Web principles, each web application
>> controls 100% what and how the client gets via this really powerful concept
>> of hypermedia. It is unlikely that the world is going to adopt a standard
>> that forces implementers to take several steps back on this kind of
>> autonomy. The diversity is what gives service providers an edge.
>>     
>
> hold on there! you just gave two completely opposing examples. if i
> have a video player that's receiving raster lines from a distant game
> server, that's TOTALLY the opposite of a client having complete
> control over it's hypermedia input. 
What? %-)
The *server* has control, not the client. The server decides whether to 
provide a VW via video streaming, whether to send out a native piece of 
code that represents the "viewer" or whether to send JavaScript. The 
client simply accepts whatever the server sends.

If the VWRAP protocol says: "servers send capabilities of assets to 
clients and clients pull the assets by invoking those capabilities and 
then mash it up and render it" you're doing very strong assumptions 
about the viewer; you're basically excluding the video player (because 
there is no asset data to pull). Point is: capabilities (or CORS) are an 
implementation option of the application. They are not the only option, 
and they are not fundamental for interoperability -- at least certainly 
not the asset-related capabilities.

This was my comment to one of the sections where you go into explaining 
this mashup.

> if i simply started streaming an
> OnLive session of someone doing SecondLife in a flash based video
> player, there's absolutely no way to guarantee that the data used to
> create the scene would be available to the client.
>
>   
>> The second point is: when we have all that variety of viewer implementations
>> that are all equally accepted by the web browser, we are still to cope with
>> portability of user agent simulation state between those worlds -- and
>> that's the bottom line for interoperability of virtual worlds on the Web.
>> I'm interested in this, because it's much more foundational than the variety
>> of virtual world implementation options.
>>     
>
> also... the virtual world is not a web application.
>
> if you look at typical web apps, the mashing up is usually done at the
> server side, turned into HTML and then sent to the browser.
>
> we're starting to see a lot more apps where JavaScript is used to do
> mashups in the client, but...
>
> VWRAP was chartered to work on server-authoritative worlds (like
> Second Life and OpenSim.) that means there's a lot of state in the
> simulator. it sounds like you want to open this state up and push its
> simulation to the edge of the network (and thus support
> co-simulation.)
>   
OpenSimulator does not impose anything wrt the client. The client 
representation on the server is a plugin. Therefore, it can easily 
support JavaScript viewers, which is something that I am more and more 
interested in.

> did i read that right? did you really just say that virtual worlds are
> client web apps?
>   

I'm saying that virtual worlds are web applications. I don't know what 
"client web apps" are. Are you saying JavaScript-heavy? If so, yes, 
maybe, if they don't use video streaming. Like Facebook, but with a 3D 
viewer coming in to the client as hypermedia -- if we are to use regular 
web browsers. We can use phat clients, too, that hard-code some viewer.

This doesn't work very well today, but it will be here in a couple of 
years.