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

[Meadhbh Hamrick <[e-mail]>]

kevin mentioned he had a javascript based virtual world simulator that
ran in a browser.

i'm surprised it can support multiple users.

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



On Wed, Sep 22, 2010 at 1:52 PM, Dan Olivares <[e-mail]> wrote:
> I thought the JavaScript portion of this discussion was out of scope.
>
> A client is a client whether it's implemented in JavaScript in a web browser
> or if it's implemented as a native application running on a machine.   A
> browser+javascript based client isn't more relevant then any other client in
> technical terms.
>
> A server can serve a javascript application that then makes use of what we
> decide here.
> It isn't necessary to assume that it always will be a web browser +
> javascript application to produce an effective standard.
>
> Regards
>
> Dan
>
>
>
> On Wed, Sep 22, 2010 at 4:45 PM, Meadhbh Hamrick <[e-mail]>
> wrote:
>>
>> um. since when is UDP a "web technology"?
>>
>> also, the javascript server you have running in your browser, if
>> you're behind a NATted firewall, doesn't that require you to
>> manipulate your firewall to route a public port/address to your
>> browser?
>>
>> --
>> meadhbh hamrick * it's pronounced "maeve"
>> @OhMeadhbh * http://meadhbh.org/ * [e-mail]
>>
>>
>>
>> On Wed, Sep 22, 2010 at 1:38 PM,  <[e-mail]> wrote:
>> > 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
>> >>
>> >>
>> >
>> >
>> _______________________________________________
>> vwrap mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/vwrap
>
>