Re: [vwrap] one question

[Morgaine <[e-mail]>]

Kevin, that's a pretty nice application, but your subsequent comments don't
follow.

The Web is continually expanding in extent, application and in capability,
but don't mistake *interfacing* for *convergence*.  As an example, IRC and
the Web are not converging either, it's just that the Web has developed
interface portals to IRC networks.  The IRC system is not about to modify
its protocols and networks just because Web fans insist on using Web
browsers to access IRC.  What we're seeing is the growth of interfaces on
the Web, not convergence of the systems themselves.  To a user these two
things might appear to be one and the same thing, but that's an illusion.
As techs we can look into the systems directly, and so we know that they're
not converging at all.

Regarding VWs and the Web "being separate", well they are separate.  They're
not **isolated** from each other because they interact, but they are
certainly separate.  They have distinct identities, very different
semantics, and VWs have many more degrees of freedom and hence far greater
potential capability.  And again, don't confuse interfaces with convergence
--- just because people give the Web some interfaces to VWs doesn't mean
that the semantics of the Web are going to change.

Your final point was "being used in the wrong way".  Well I never said
"wrong", I just said that some tools are not a natural fit for some
problems.  The Web browser is a natural fit for browsing the Web, but that
doesn't mean that it's a natural fit for accessing all digital
technologies.  It's actually an extremely poor tool for some things, for
example UIs.

The classic recent example of this was the dreadful Web interface to Google
Wave, one of the most powerful technologies of recent times but placed in a
straightjacket by the terribly limited UI capability of the browser.  Web
tech will improve in this area of course, and HTML5 certainly holds much
promise, but browser-based UIs have 20 years of lost Human Interface power
and ergonomics to make up first.


Morgaine.





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

On Thu, Sep 23, 2010 at 7:38 PM, <[e-mail]> wrote:

>  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.
>
>
>