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

Meadhbh Hamrick <ohmeadhbh@gmail.com> Wed, 22 September 2010 20:46 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 99B083A6AB7 for <vwrap@core3.amsl.com>; Wed, 22 Sep 2010 13:46:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.832
X-Spam-Level:
X-Spam-Status: No, score=-1.832 tagged_above=-999 required=5 tests=[AWL=0.767, 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 mDh2MwdPVUjJ for <vwrap@core3.amsl.com>; Wed, 22 Sep 2010 13:46:37 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 39F033A6814 for <vwrap@ietf.org>; Wed, 22 Sep 2010 13:46:25 -0700 (PDT)
Received: by wyi11 with SMTP id 11so1023416wyi.31 for <vwrap@ietf.org>; Wed, 22 Sep 2010 13:46:52 -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 :content-transfer-encoding; bh=82RYiwVWf6v5HOMUVIDEaeJzbnyinmk+O9695nFmCyA=; b=XIWGat/MtTtZ0Y/jznZb9L4IFYz8/qWo31EZHIvn+pT+HKUYW3EXTwiIbL4TOm4nRr tJ+G/vVw1w1gi5zMHbXDHi4z6S7iFhzxMgqbQp99OwrMTw/DskEzW9I7jQXAHUayjN51 1hTiBoP34uLFWoJGd8qPwzMbZ73/rVgmAZ1AQ=
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:content-transfer-encoding; b=d6Np9zw4/MIuU2Ch2gLQJrgb3KDcil10m2dPbNRxh+UcnfpBe0Uf24HZctXOMt4VyM EQnyI0ONpcWj7A633DVq9QalrTYeyaWCcNIG3heP5RCd8yjTgXb5zlsS7npn3ZoN9eBl ngHA6QFn5902e6k9r7BDlOQMKCPaqbwUgECxQ=
Received: by 10.216.165.16 with SMTP id d16mr684121wel.0.1285188412436; Wed, 22 Sep 2010 13:46:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.170.82 with HTTP; Wed, 22 Sep 2010 13:46:32 -0700 (PDT)
In-Reply-To: <1A5F900B3E0343479D130F7A8DBB65E6@TWEEDY64>
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> <4B19233103A440D78CAD32106AF446F2@TWEEDY64> <AANLkTimBHfDU2yAaU=+7DxqLMmymyL6oEii6u1+b830N@mail.gmail.com> <1A5F900B3E0343479D130F7A8DBB65E6@TWEEDY64>
From: Meadhbh Hamrick <ohmeadhbh@gmail.com>
Date: Wed, 22 Sep 2010 13:46:32 -0700
Message-ID: <AANLkTik2jdMz=TO6dOSg3bMrGPdoA6+Q4d1jkGgFi=QE@mail.gmail.com>
To: kevin.tweedy@xrgrid.com
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: vwrap@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:46:38 -0000

okay. how many people are in your virtual world?

--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com



On Wed, Sep 22, 2010 at 1:43 PM,  <kevin.tweedy@xrgrid.com> wrote:
> I currently have psychics running on the client.  But why do I even need to
> have physics?  That is a VWRAP requirement?
>
> Simulation takes place on the client.
>
> For or nursing virtual space, the virtual world is a standalone space that
> everyone gets their unique copy from.  It does allow for observers and we
> can sync object and UI events to them.
>
> I feel we are making so many assumptions about the virtual world and how it
> is implemented.  I don't really understand why you are asking the question
>
> K.
>
>
> -----Original Message-----
> From: Meadhbh Hamrick [mailto:ohmeadhbh@gmail.com]
> Sent: Wednesday, September 22, 2010 4:25 PM
> To: kevin.tweedy@xrgrid.com
> Subject: Re: [vwrap] Consensus? What exactly should be in the protocol
>
> where does physics simulation take place?
>
> in the client or on a server somewhere?
> --
> meadhbh hamrick * it's pronounced "maeve"
> @OhMeadhbh * http://meadhbh.org/ * OhMeadhbh@gmail.com
>
>
>
> On Wed, Sep 22, 2010 at 1:19 PM,  <kevin.tweedy@xrgrid.com> wrote:
>> Why is virtual world not a web app?  My virtual world runs in a browser
> and
>> can talk to my webserver.
>>
>> K.
>>
>> -----Original Message-----
>> From: vwrap-bounces@ietf.org [mailto:vwrap-bounces@ietf.org] On Behalf Of
>> Meadhbh Hamrick
>> Sent: Wednesday, September 22, 2010 3:37 PM
>> To: lopes@ics.uci.edu
>> Cc: vwrap@ietf.org; vwrap-bounces@ietf.org
>> Subject: Re: [vwrap] Consensus? What exactly should be in the protocol
>>
>> On Wed, Sep 22, 2010 at 11:59 AM, Cristina Videira Lopes
>> <lopes@ics.uci.edu> wrote:
>>> Cristina Videira Lopes wrote:
>>>>
>>>> You can dictate that. But then this will be completely irrelevant in a
>>>> couple of years when WebGL is actually usable or when Google finishes
>> their
>>>> virtual machine for running safe native code on browsers.
>>>
>>> ...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. if i simply started streaming an
>> OnLive session of someone doing SecondLife in a flash based video
>> player, there's absolutely no way to guarantee that the data used to
>> create the scene would be available to the client.
>>
>>> The second point is: when we have all that variety of viewer
>> implementations
>>> that are all equally accepted by the web browser, we are still to cope
>> with
>>> portability of user agent simulation state between those worlds -- and
>>> that's the bottom line for interoperability of virtual worlds on the Web.
>>> I'm interested in this, because it's much more foundational than the
>> variety
>>> of virtual world implementation options.
>>
>> also... the virtual world is not a web application.
>>
>> if you look at typical web apps, the mashing up is usually done at the
>> server side, turned into HTML and then sent to the browser.
>>
>> we're starting to see a lot more apps where JavaScript is used to do
>> mashups in the client, but...
>>
>> VWRAP was chartered to work on server-authoritative worlds (like
>> Second Life and OpenSim.) that means there's a lot of state in the
>> simulator. it sounds like you want to open this state up and push its
>> simulation to the edge of the network (and thus support
>> co-simulation.)
>>
>> did i read that right? did you really just say that virtual worlds are
>> client web apps?
>>
>>>
>>> _______________________________________________
>>> vwrap mailing list
>>> vwrap@ietf.org
>>> https://www.ietf.org/mailman/listinfo/vwrap
>>>
>> _______________________________________________
>> vwrap mailing list
>> vwrap@ietf.org
>> https://www.ietf.org/mailman/listinfo/vwrap
>>
>>
>
>