Re: [vwrap] Technical basis for VW client in a web browser?

Cristina Videira Lopes <lopes@ics.uci.edu> Sun, 19 December 2010 16:28 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 5E5A13A6809 for <vwrap@core3.amsl.com>; Sun, 19 Dec 2010 08:28:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.684
X-Spam-Level:
X-Spam-Status: No, score=-1.684 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_51=0.6, SARE_MILLIONSOF=0.315]
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 hTOtfRH9t1Xc for <vwrap@core3.amsl.com>; Sun, 19 Dec 2010 08:28:27 -0800 (PST)
Received: from colin-baker-v0.ics.uci.edu (colin-baker-v0.ics.uci.edu [128.195.1.153]) by core3.amsl.com (Postfix) with ESMTP id 819613A680C for <vwrap@ietf.org>; Sun, 19 Dec 2010 08:28:27 -0800 (PST)
Received: from [169.234.242.112] (susan-foreman.ics.uci.edu [128.195.1.134]) (authenticated bits=0) by colin-baker-v0.ics.uci.edu (8.13.8/8.13.8) with ESMTP id oBJGUAVh029256 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for <vwrap@ietf.org>; Sun, 19 Dec 2010 08:30:14 -0800
Message-ID: <4D0E3316.1010504@ics.uci.edu>
Date: Sun, 19 Dec 2010 08:30:14 -0800
From: Cristina Videira Lopes <lopes@ics.uci.edu>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: vwrap@ietf.org
References: <AANLkTintjQdAS=EWfiRu3oWenB42LKsNzJPDJ+5ofBRO@mail.gmail.com> <AANLkTinhWObg6Te2VtGYKXsxBG5=gVDS5szmjtLeOgnm@mail.gmail.com> <AANLkTikYn-iA7osXT_oW8rL61GhK57pp7uJVmTSGVvj7@mail.gmail.com> <AANLkTikFWUxQyT9aNFBk7-Fdb5bNdFT9Bj-dehqVP0WN@mail.gmail.com> <AANLkTikFiJsLf2jNnJve90oXpChzFNc+6PQiYmWtMW9y@mail.gmail.com>
In-Reply-To: <AANLkTikFiJsLf2jNnJve90oXpChzFNc+6PQiYmWtMW9y@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ICS-MailScanner-Information: Please send mail to helpdesk@ics.uci.edu or more information
X-ICS-MailScanner-ID: oBJGUAVh029256
X-ICS-MailScanner: Found to be clean
X-ICS-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-1.125, required 5, autolearn=disabled, ALL_TRUSTED -1.44, SARE_MILLIONSOF 0.32)
X-ICS-MailScanner-From: lopes@ics.uci.edu
Subject: Re: [vwrap] Technical basis for VW client in a web browser?
X-BeenThere: vwrap@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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: Sun, 19 Dec 2010 16:28:28 -0000

Morgaine says:

 > Has anyone seen a well argued technical assessment supporting the 
concept of "VW client in a browser"?

"VW client in a browser" has been a reality for many years, I'm not sure 
it needs to be argued for. Hundreds of millions of people use them on a 
regular basis. All Flash-based virtual worlds out there are as much 
interactive virtual worlds as Second Life, they're just poorer in terms 
of graphics. We're now starting to see a lot of interest in 
Unity3D-based environments, namely the webplayer, which provides 
excellent graphics on the browser (among other delivery platforms). And 
the next version of Flash supporting 3D is around the corner.

Browser plugin approaches, such as Flash and Unity3D, are perfectly 
valid approachesfor Web apps. They're all part of the hypermedia concept 
upon which the Web stands: the "players" (programs) are associated with 
specific MIME types that web clients may or may not be equipped to 
interpret. Technically speaking, these plugins can do anything you want 
them to do -- there is no difference between a dedicated, independently 
installed client, and a client that runs as a browser plugin. Some 
plugins are so important that they become de-facto standards, at least 
until something better comes along -- that's the case with Flash.

Linden Lab could deliver the SL viewer as a browser plugin, too, 
especially now that OpenSim exists. It wouldn't solve the firewall 
issues associated with the LLUDP protocol. But it would go along the 
lines of developing a platform for 3rd-party 3D web application 
development, which is the sorely needed solution space for massifying 
online 3D that Flash and Unity3d are in.

If you're in the business of creating your own virtual world from 
scratch, a dedicated client or a standard media like mpeg video may make 
more sense than a browser plugin. However, if you're in the business of 
being a middleware of sorts that allows others to create and host their 
own applications (like Adobe Flash and Unity3D), then a browser plugin 
-- paired with the proper server-side component (like SmartFoxServer or 
OpenSim) -- makes a lot of sense, because your users' users need only to 
install a plugin -- a one-time, automatic, well-oiled process that 
doesn't feel like a separate download, and that doesn't force people to 
start up this other program every time they want to visit the VW.

For the time being, JavaScript+WebGL+WebSockets can only support very 
simple interactions. Eventually, this combo may be good enough to 
replace these dedicated plugins. But if/while that doesn't happen, and 
even if it happens, browser plugins are as good an approach as they have 
been for the past 15 years. One can only hope there will be more 
alternatives to Flash and Unity3D. I actually believe that the SL viewer 
could be a 3rd alternative.

(OpenSim is in par with SmartFoxServer, but open source: OpenSim is a 
platform for multi-user 3D application development, just like SmartFox; 
it just happens to have started around the LL protocol instead of around 
Flash.)

Regards,
Crista