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

[Meadhbh Hamrick <[e-mail]>]

the purpose of defining data standards is so that you can communicate
things beween servers and between servers and clients.

the web is not the only place where virtual worlds will be rendered.
so while it is possible to define javascript to interpret messages in
proprietary protiocols, this group is interested in defining the wire
formats that communicate information about virtual worlds.
--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadhbh.org/ * [e-mail]



On Wed, Sep 22, 2010 at 1:32 PM, Cristina Videira Lopes
<[e-mail]> wrote:
> Meadhbh Hamrick wrote:
>>>>>
>>>>> ...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.
>>>
>>>
>>
>> my point is that if you're going to depend on CORS in the client to do
>> app mashup, and one of the servers sends you HTML that includes a
>> flash plugin that only sends video of a distantly rendered SecondLife
>> app window, you're going to have a hard time picking apart the data
>> that went into composing the video by services from other servers.
>>
>
> Exactly. So you don't pick it apart. And that's a decision of whoever wrote
> the web application. It's not anyone's business.
>
>
>
>