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

Joshua Bell <josh@lindenlab.com> Thu, 16 December 2010 17:05 UTC

Return-Path: <josh@lindenlab.com>
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 906CA3A693D for <vwrap@core3.amsl.com>; Thu, 16 Dec 2010 09:05:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.376
X-Spam-Level:
X-Spam-Status: No, score=-102.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 tSsgLCh7CEgM for <vwrap@core3.amsl.com>; Thu, 16 Dec 2010 09:05:44 -0800 (PST)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id E7DA53A691F for <vwrap@ietf.org>; Thu, 16 Dec 2010 09:05:43 -0800 (PST)
Received: by yxt33 with SMTP id 33so1880373yxt.31 for <vwrap@ietf.org>; Thu, 16 Dec 2010 09:07:28 -0800 (PST)
MIME-Version: 1.0
Received: by 10.90.80.18 with SMTP id d18mr1040987agb.31.1292519248064; Thu, 16 Dec 2010 09:07:28 -0800 (PST)
Received: by 10.90.23.9 with HTTP; Thu, 16 Dec 2010 09:07:28 -0800 (PST)
In-Reply-To: <AANLkTikYn-iA7osXT_oW8rL61GhK57pp7uJVmTSGVvj7@mail.gmail.com>
References: <AANLkTintjQdAS=EWfiRu3oWenB42LKsNzJPDJ+5ofBRO@mail.gmail.com> <AANLkTinhWObg6Te2VtGYKXsxBG5=gVDS5szmjtLeOgnm@mail.gmail.com> <AANLkTikYn-iA7osXT_oW8rL61GhK57pp7uJVmTSGVvj7@mail.gmail.com>
Date: Thu, 16 Dec 2010 09:07:28 -0800
Message-ID: <AANLkTikFWUxQyT9aNFBk7-Fdb5bNdFT9Bj-dehqVP0WN@mail.gmail.com>
From: Joshua Bell <josh@lindenlab.com>
To: vwrap@ietf.org
Content-Type: multipart/alternative; boundary=0016361e878aa5711704978a168d
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: Thu, 16 Dec 2010 17:05:48 -0000

On Thu, Dec 16, 2010 at 3:01 AM, Morgaine <morgaine.dinova@googlemail.com>wrote;wrote:

> So yes, what I'm looking for here are some substantive technical reasons
> for pursuing the browser route for VW clients beyond small, cut-down
> introductory ones.  So far I've not seen any good technical reasons for it
> at all, and in contrast, technical reasons why it could be a *bad* host
> platform are abundant.


Lisa Dusseault and I wrote a paper (linked from here) last year outlining
some of the technical challenges. The good news is that most of the
challenges are being actively addressed by browser vendors and the Web
community in general.

At a high level, a 3D immersive VW client needs these subsystems:

   - User Interface
   - 3D Rendering
   - Networking
   - Audio and Voice
   - Logic
   - Application Host/Framework

The Second Life Viewer, for example, uses:

   - UI: custom toolkit on top of OpenGL (with declarative definitions
   called XUI)
   - 3D: custom rendering engine on top of OpenGL
   - Net: custom messaging library using UDP plus HTTP libraries like CURL
   - Audio: FMOD/OpenAL (general) and Vivox (voice)
   - Logic: application logic in C++
   - App: custom app host/framework for windowing/OS integration

Looking at the Web as a platform, the following are available:

   - UI: HTML/CSS/JS; Flash; Silverlight; Unity3D
   - 3D: Flash; Unity3D; WebGL; custom plug-ins; server-side rendering to
   video
   - Net: XHR; Flash; WebSockets
   - Audio: Flash; HTML5 Audio; Vivox plugin
   - Logic: JavaScript; Flash ActionScript; Unity3D C#
   - App: Web browser

Obviously, that's a mish-mash of different technologies; one of the pushes
of the "HTML5" effort - using that term in it's broad marketing sense and
covering the various technologies like WebGL, WebSockets, WebWorkers, CSS3,
ES5, etc etc - is to create a more unified, Standards-based platform for
application development.

Efforts such as KataLabs KataSpace (http://www.sirikata.com/blog/?p=184) -
which is built using "HTML5" tech only - shows that this is feasible today,
to some degree.

To drill into the technical impediments and how they will need to be
addressed:

   - UI: none, really; HTML for UI is a mature technology. It's true that
   many implementations are poor, but this is not a blocker.
   - 3D: effectively 0% of users have WebGL now, but that will change
   significantly within 12 months; Flash 3D is currently weak but Molehill is
   due in late 2011 and should have fast uptake. Unity is available now but is
   a plugin which turns away many users. (Yes, technically, Flash is a plugin
   too, but it's a special case both technically and socially); server-side
   rendering is available now but there are many open variables
   - Net: WebSockets is not stabilized yet and does not offer UDP (which may
   be necessary for some low-latency scenarios); further, cross-platform
   - Audio: HTML5 audio for presentation is progressing well, but streaming
   voice capture has not yet been tackled and I haven't seen streaming-down of
   realtime sessions yet. Vivox has a plugin available today, however, that can
   be driven by..
   - Logic: JavaScript appears adequate for most application logic, but the
   amount of data that needs to be processed per frame in a complex world like
   SL is significant - far more than most games. Most WebGL demos so far have
   extremely simple requirements.
   - App: obviously, in the web an app lives in a browser tab. This implies
   far less control over system resources and the user's attention, and affects
   the implied user model - fast startup, tear-down with little warning,
   integration into navigation stack (e.g. back/forward), simultaneous
   sessions, etc.

Like most applications, attempting to simply recreate the experience as-is
within the browser is probably not the right approach, and will lead to a
poor experience. That said, I don't think there are significant technical
barriers, and certainly we already have examples where functional VW clients
implemented in the browser have been created.

-- Josh