Re: [vwrap] one question

[Morgaine <[e-mail]>]

On Thu, Sep 23, 2010 at 4:20 PM, Cristina Videira Lopes
<[e-mail]>wrote;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;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.
>
>