Re: [vwrap] Consensus? What exactly should be in the protocol

Meadhbh Hamrick <ohmeadhbh@gmail.com> Wed, 22 September 2010 20:24 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 B706728C17C; Wed, 22 Sep 2010 13:24:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.766
X-Spam-Level:
X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599]
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 rvgTnMqMFYyc; Wed, 22 Sep 2010 13:24:15 -0700 (PDT)
Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by core3.amsl.com (Postfix) with ESMTP id 2C6323A6B96; Wed, 22 Sep 2010 13:23:14 -0700 (PDT)
Received: by wwb18 with SMTP id 18so608939wwb.1 for <multiple recipients>; Wed, 22 Sep 2010 13:23:41 -0700 (PDT)
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=FKam9RQhim9kejikoaIc3XZCyghC8OdZO/M5XIJ3zB8=; b=ELnFublY3WUaLLs7ilstqroqUhLh49W1q3hpMNWuwoGcM8upTiRq9ioF2dnUt26m3U dRHYzhXQllg4YBTaqB3mKCbb6t9D6h299CTxE/g6TZe48yWWLoSvRzUElWHaeBBdePlv oB6CRT5KM86I5BrsKHu9pK4vZl9oSl67afHqw=
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=fgGNOlvj8KXTBhMfs4rSCtTheSh9mUwyPs1JnOhlZfNB2Ut0KQrU4u9aIM4P0MxfST /xoKuFhgeNAiBQicuxQUMTxYID/0gqU/PJe7952kSXVSNLIqSy1/wseQ50l4GWmPpewK GmWTk84jTNIi4qHqmLVnNQ003nVXzmWuUWIg0=
Received: by 10.216.169.136 with SMTP id n8mr7451208wel.65.1285187020942; Wed, 22 Sep 2010 13:23:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.170.82 with HTTP; Wed, 22 Sep 2010 13:23:20 -0700 (PDT)
In-Reply-To: <4C9A61EC.7020304@ics.uci.edu>
References: <AANLkTinxpGRZ9PEWQx=KvaBNGBba4Z+P+SaP4N80VGV1@mail.gmail.com> <E2109887-F5B2-4742-B4F7-1C4655A2DD8B@ics.uci.edu> <62BFE5680C037E4DA0B0A08946C0933D012670D0C9@rrsmsx506.amr.corp.intel.com> <4C9A070B.3070202@hp.com> <AANLkTinVX6Uo2S+7ocdTiVfiTFa9wxM=x1Cncyi5ij86@mail.gmail.com> <4C9A17FC.9090308@ics.uci.edu> <OF98CA2B26.9D4927A8-ON852577A6.00572945-852577A6.0060FB5D@us.ibm.com> <4C9A45FC.6030709@ics.uci.edu> <4C9A5226.2080601@ics.uci.edu> <AANLkTintT3c0aeJia=jk=EYxooOjm5M8Ozbnt5KWibB0@mail.gmail.com> <4C9A61EC.7020304@ics.uci.edu>
From: Meadhbh Hamrick <ohmeadhbh@gmail.com>
Date: Wed, 22 Sep 2010 13:23:20 -0700
Message-ID: <AANLkTims7efvsRKLy7=6_fvbiaytYfSP8QU0UCODvk_a@mail.gmail.com>
To: lopes@ics.uci.edu
Content-Type: text/plain; charset=ISO-8859-1
Cc: vwrap@ietf.org, vwrap-bounces@ietf.org
Subject: Re: [vwrap] Consensus? What exactly should be in the protocol
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: Wed, 22 Sep 2010 20:24:16 -0000

>>>
>>> ...or when server-side streaming goes mainstream, and being in a virtual
>>> world is as simple as running a video player plus a few JavaScript/native
>>> back channels to the server.
>>>
>>> First point is: according to the Web principles, each web application
>>> controls 100% what and how the client gets via this really powerful
>>> concept
>>> of hypermedia. It is unlikely that the world is going to adopt a standard
>>> that forces implementers to take several steps back on this kind of
>>> autonomy. The diversity is what gives service providers an edge.
>>>
>>
>> hold on there! you just gave two completely opposing examples. if i
>> have a video player that's receiving raster lines from a distant game
>> server, that's TOTALLY the opposite of a client having complete
>> control over it's hypermedia input.
>
> What? %-)
> The *server* has control, not the client. The server decides whether to
> provide a VW via video streaming, whether to send out a native piece of code
> that represents the "viewer" or whether to send JavaScript. The client
> simply accepts whatever the server sends.
>
> If the VWRAP protocol says: "servers send capabilities of assets to clients
> and clients pull the assets by invoking those capabilities and then mash it
> up and render it" you're doing very strong assumptions about the viewer;
> you're basically excluding the video player (because there is no asset data
> to pull). Point is: capabilities (or CORS) are an implementation option of
> the application. They are not the only option, and they are not fundamental
> for interoperability -- at least certainly not the asset-related
> capabilities.
>
> This was my comment to one of the sections where you go into explaining this
> mashup.
>

my point is that if you're going to depend on CORS in the client to do
app mashup, and one of the servers sends you HTML that includes a
flash plugin that only sends video of a distantly rendered SecondLife
app window, you're going to have a hard time picking apart the data
that went into composing the video by services from other servers.