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

Meadhbh Hamrick <ohmeadhbh@gmail.com> Thu, 16 December 2010 17:33 UTC

Return-Path: <ohmeadhbh@gmail.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 886233A695D for <vwrap@core3.amsl.com>; Thu, 16 Dec 2010 09:33:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 Bjp4t-3Cigt0 for <vwrap@core3.amsl.com>; Thu, 16 Dec 2010 09:33:01 -0800 (PST)
Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 8E1593A690D for <vwrap@ietf.org>; Thu, 16 Dec 2010 09:33:01 -0800 (PST)
Received: by qyj19 with SMTP id 19so3493772qyj.10 for <vwrap@ietf.org>; Thu, 16 Dec 2010 09:34:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=2La2+cycfxwJKB0k34vcab68fXxbUD+N0JKJq802MzY=; b=tzz+iuYj5/PByW9B/bAM+v+/SuwyvLNFDEaXNY0XZKy+toDDjRQuFCq//i54i3fz/I 1pcLfZL5WUN07PVC212OyNBxSU6pWh2dShEFxIppFUQ1hCJPltigXPFFGz+DFEYV+F/h +Vwp+HeBhZe4SkQJ1LGlYb07cct71bitBB50c=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=NdeU37ivXYNXPX1zrMNkPmCDcdFQK5m+cIs/v7Jv0CgBr3totes1Rc5kJq4mZN2Fx3 Uq/HoeY6y+eXLC6po2XL3BTlH1YUpkgbdqhd9BGzHc2tSb0Kvnlmqll6RbOBW3hj4h2Q vfvfUL+3+njkagTShs/7xbRzy6a/g3WE14zKw=
Received: by 10.224.20.68 with SMTP id e4mr3563887qab.326.1292520886446; Thu, 16 Dec 2010 09:34:46 -0800 (PST)
MIME-Version: 1.0
Received: by 10.220.99.21 with HTTP; Thu, 16 Dec 2010 09:34:26 -0800 (PST)
In-Reply-To: <AANLkTikFWUxQyT9aNFBk7-Fdb5bNdFT9Bj-dehqVP0WN@mail.gmail.com>
References: <AANLkTintjQdAS=EWfiRu3oWenB42LKsNzJPDJ+5ofBRO@mail.gmail.com> <AANLkTinhWObg6Te2VtGYKXsxBG5=gVDS5szmjtLeOgnm@mail.gmail.com> <AANLkTikYn-iA7osXT_oW8rL61GhK57pp7uJVmTSGVvj7@mail.gmail.com> <AANLkTikFWUxQyT9aNFBk7-Fdb5bNdFT9Bj-dehqVP0WN@mail.gmail.com>
From: Meadhbh Hamrick <ohmeadhbh@gmail.com>
Date: Thu, 16 Dec 2010 09:34:26 -0800
Message-ID: <AANLkTinO4ysKaainTV_6aVtmvHtYaCR+AMfNPhM5CyVc@mail.gmail.com>
To: Joshua Bell <josh@lindenlab.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: vwrap@ietf.org
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:33:02 -0000

just to add to your statements:

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

the DEVICE tag is getting a little bit of momentum, driven by people
in the VoIP / video conferencing space. i made a very ugly patch for
firefox to demonstrate how the DEVICE tag could capture microphone
input. i have a standing date with the mozilla people for when i turn
it into a plugin. so who knows, maybe in a couple years, there will be
a real live standard for getting A/V device input into a browser's
execution environment.

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

though i'm a bit of a JavaScript fan, i think it's an open question
whether JS could handle the types of data rates SL sends at a viewer.
this being said, a "light" experience with less detail, fewer
textures, etc. is probably do-able.

-cheers
-meadhbh