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
- [vwrap] Technical basis for VW client in a web br… Morgaine
- Re: [vwrap] Technical basis for VW client in a we… Dahlia Trimble
- Re: [vwrap] Technical basis for VW client in a we… Morgaine
- Re: [vwrap] Technical basis for VW client in a we… Joshua Bell
- Re: [vwrap] Technical basis for VW client in a we… Meadhbh Hamrick
- Re: [vwrap] Technical basis for VW client in a we… Peter Saint-Andre
- Re: [vwrap] Technical basis for VW client in a we… Morgaine
- Re: [vwrap] Technical basis for VW client in a we… JohnnyB Hammerer
- Re: [vwrap] Technical basis for VW client in a we… peter host
- Re: [vwrap] Technical basis for VW client in a we… Brian Hurley
- Re: [vwrap] Technical basis for VW client in a we… Morgaine
- Re: [vwrap] Technical basis for VW client in a we… Morgaine
- Re: [vwrap] Technical basis for VW client in a we… Cristina Videira Lopes
- Re: [vwrap] Technical basis for VW client in a we… peter host
- Re: [vwrap] Technical basis for VW client in a we… SM
- Re: [vwrap] Technical basis for VW client in a we… Meadhbh Hamrick
- Re: [vwrap] Technical basis for VW client in a we… Dahlia Trimble
- Re: [vwrap] Technical basis for VW client in a we… Hurliman, John
- Re: [vwrap] Technical basis for VW client in a we… Mic Bowman
- Re: [vwrap] Technical basis for VW client in a we… Morgaine
- Re: [vwrap] Technical basis for VW client in a we… Dahlia Trimble
- Re: [vwrap] Technical basis for VW client in a we… Dan Olivares
- Re: [vwrap] Technical basis for VW client in a we… Dahlia Trimble
- Re: [vwrap] Technical basis for VW client in a we… Dan Olivares
- Re: [vwrap] Technical basis for VW client in a we… Joshua Bell
- Re: [vwrap] Technical basis for VW client in a we… Dahlia Trimble
- Re: [vwrap] Technical basis for VW client in a we… Morgaine
- Re: [vwrap] Technical basis for VW client in a we… Dahlia Trimble
- Re: [vwrap] Technical basis for VW client in a we… Dzonatas Sol
- Re: [vwrap] Technical basis for VW client in a we… Dzonatas Sol