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

[<[e-mail]>]

I also have a game server that uses TCP/UDP that runs from my server, to
handle the object synchronization.  My point is I am using what all are
considered web technologies.

I was more making the point, why even say it is a web app or not.  As long
the exposed behavior of my system supports the protocols and formats that
are needed it can interact with other systems.

And the URL is the web page that the world is hosted on.  And I had 300+
avatars walking around in this web page.

K.

-----Original Message-----
From: Meadhbh Hamrick [mailto:[e-mail]] 
Sent: Wednesday, September 22, 2010 4:26 PM
To: [e-mail]
Subject: Re: [vwrap] Consensus? What exactly should be in the protocol

also. how many other people are connected to your javascript virtual
region simulator running in your browser?

what URL do you give them to connect to it?

--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadhbh.org/ * [e-mail]



On Wed, Sep 22, 2010 at 1:19 PM,  <[e-mail]> wrote:
> Why is virtual world not a web app?  My virtual world runs in a browser
and
> can talk to my webserver.
>
> K.
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Meadhbh Hamrick
> Sent: Wednesday, September 22, 2010 3:37 PM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: Re: [vwrap] Consensus? What exactly should be in the protocol
>
> 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. 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.)
>
> did i read that right? did you really just say that virtual worlds are
> client web apps?
>
>>
>> _______________________________________________
>> vwrap mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/vwrap
>>
> _______________________________________________
> vwrap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/vwrap
>
>