Re: [vwrap] one question

Cristina Videira Lopes <lopes@ics.uci.edu> Thu, 23 September 2010 15:20 UTC

Return-Path: <lopes@ics.uci.edu>
X-Original-To: vwrap@core3.amsl.com
Delivered-To: vwrap@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B2623A69F3 for <vwrap@core3.amsl.com>; Thu, 23 Sep 2010 08:20:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.371
X-Spam-Level:
X-Spam-Status: No, score=-2.371 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x2Wdb68R9WHE for <vwrap@core3.amsl.com>; Thu, 23 Sep 2010 08:20:25 -0700 (PDT)
Received: from david-tennant-v0.ics.uci.edu (david-tennant-v0.ics.uci.edu [128.195.1.174]) by core3.amsl.com (Postfix) with ESMTP id 826583A69EC for <vwrap@ietf.org>; Thu, 23 Sep 2010 08:20:25 -0700 (PDT)
Received: from [169.234.251.228] (paul-mcgann.ics.uci.edu [128.195.1.146]) (authenticated bits=0) by david-tennant-v0.ics.uci.edu (8.13.8/8.13.8) with ESMTP id o8NFKkdw001235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Sep 2010 08:20:47 -0700
Message-ID: <4C9B7041.50908@ics.uci.edu>
Date: Thu, 23 Sep 2010 08:20:33 -0700
From: Cristina Videira Lopes <lopes@ics.uci.edu>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Morgaine <morgaine.dinova@googlemail.com>
References: <4C9AB1BB.2010008@ics.uci.edu> <AANLkTi=fz6LhpRaTJr7Bu4KsXS93-B0B7SzjH4PwDGuc@mail.gmail.com>
In-Reply-To: <AANLkTi=fz6LhpRaTJr7Bu4KsXS93-B0B7SzjH4PwDGuc@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------000400050202090102060001"
X-ICS-MailScanner-Information: Please send mail to helpdesk@ics.uci.edu or more information
X-ICS-MailScanner-ID: o8NFKkdw001235
X-ICS-MailScanner: Found to be clean
X-ICS-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-1.439, required 5, autolearn=disabled, ALL_TRUSTED -1.44, HTML_MESSAGE 0.00)
X-ICS-MailScanner-From: lopes@ics.uci.edu
Cc: "vwrap@ietf.org" <vwrap@ietf.org>
Subject: Re: [vwrap] one question
X-BeenThere: vwrap@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: lopes@ics.uci.edu
List-Id: Virtual World Region Agent Protocol - IETF working group <vwrap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/vwrap>, <mailto:vwrap-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/vwrap>
List-Post: <mailto:vwrap@ietf.org>
List-Help: <mailto:vwrap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/vwrap>, <mailto:vwrap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Sep 2010 15:20:26 -0000

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.