Re: [vwrap] one question

[<[e-mail]>]

Well, take a look at this and tell me that web, internet, and virtual worlds
aren't all converging and to try to say they are separate and browser are
being used in the wrong way.

 

http://robotduck.wordpress.com/2010/09/11/hometown-gp-launched/

 

K.

 

  _____  

From: [e-mail] [mailto:[e-mail]] On Behalf Of
Morgaine
Sent: Thursday, September 23, 2010 1:53 PM
To: [e-mail]
Subject: Re: [vwrap] one question

 

On Thu, Sep 23, 2010 at 4:20 PM, Cristina Videira Lopes <[e-mail]>
wrote:

 

I think that answers your question from the VWRAP end, but I get the feeling
there's something missing still.  Perhaps I could pose a question of my own
to help the discussion:  Do you consider a "virtual world that uses the web
browser as the client" to be significantly different to a virtual world that
doesn't define the type of client?

No; I'm interested in virtual worlds that are Web applications -- no more,
no less. But the VWRAP protocol seems to be defining a specific type of
client, and hence, a specific way of writing the JavaScript program -- at
least wrt the endpoints.

 


To some extent, this embroils us in issues of direction and philosophy.
Some people say "We're trying to build the 3D Web", but they're completely
wrong, mistaking an analogy (how the Web is structured and how it exploded
in popularity) with the direction (to create a metaverse of some kind).
Sure, we hope that it'll be as large and as popular as the Web, or even more
popular, but that doesn't mean that the goal is in any way related to the
Web.

In matters of technology, we're trying to use as much Web tech as we can,
but again, that's not because virtual worlds have any actual relationship to
the Web.  It just means that we're sensibly trying to ride on the shoulders
of giants, reaping the benefits of very efficient (and cheap) Web
infrastructure.  When we link VWs to Web content, that's just because people
need their Web-side data or want to harness Web-side functionality, and it
would make no sense at all to deny them access to that from within VWs.

But again, that Web access has nothing to do with virtual worlds being in
any way related to the Web, they're not.  Indeed, they're not even Web apps,
they're Internet apps, and there's a significant difference.  (The
difference is in the data and comms models, more than merely the use of
particular protocols or ports.  IRC isn't a web app either, despite having
gateways on the Web.)

Which brings us to the thorniest issue of the lot, the client.  Browsers are
made for browsing the Web, and if at all possible one should not be trying
to bang in screws with a hammer.  If browser fans insist on using a tool
designed for a different purpose to access VWs, fine, it's their choice, but
it's also their problem if they find that it's not a natural fit.  Perhaps
they can adapt browser technology to fit better, and that would be cool, but
that task is theirs.  They shouldn't expect the very different semantics of
virtual worlds to be restricted to fit into the much narrower pigeon hole of
Web applications.


Morgaine.




==============================

On Thu, Sep 23, 2010 at 4:20 PM, Cristina Videira Lopes <[e-mail]>
wrote:

Morgaine wrote: 

But in VWRAP, it is immaterial what kind of client application runs the
client endpoint of the VWRAP protocols, so the phrase "virtual worlds that
use the web browser as the client" doesn't really make much sense in our
context.  The answer is Yes only because we scratch our heads and then
ignore the phrase as an unnecessary condition.  Sure, why not? :-)))

 

OK. So there are "client endpoints of the VWRAP protocol". Does this mean
that there are defined behaviors for a VWRAP client on those endpoints? In
other words, if my viewer is in JavaScript, I have to make the JavaScript
program do things in specific ways, and not others, in order to be able to
interoperate in VWRAP?






Admittedly, your student would probably need to do some rather unnatural
coding since the VW model is really quite distant from the Web model, and
Javascript in the browser runs sandboxed so it's an interesting question how
your client would be coaxed to talk to various external services, for
example to be able to see assets worn by visitors from other worlds.
(Remember that VWRAP is not tied to the SL model in which everything is
proxied through the current sim, a highly non-scalable arrangement.)

CORS addresses that issue (avoiding the jasonp trick).
But this exposes the point I'm trying to clarify: on the web browser, VWRAP
seems to be *forcing* application developers to use CORS, instead of leaving
that as an independent engineering decision of each application. Why?







I think that answers your question from the VWRAP end, but I get the feeling
there's something missing still.  Perhaps I could pose a question of my own
to help the discussion:  Do you consider a "virtual world that uses the web
browser as the client" to be significantly different to a virtual world that
doesn't define the type of client?

No; I'm interested in virtual worlds that are Web applications -- no more,
no less. But the VWRAP protocol seems to be defining a specific type of
client, and hence, a specific way of writing the JavaScript program -- at
least wrt the endpoints.







I would hope your answer is "No", since otherwise it would suggest that
worlds are going to Balkanize by the clients they use, which of course would
help nobody, and interop would be compromised.

 

Agreed.