Re: [vwrap] Conditioners and refineries

Dzonatas Sol <dzonatas@gmail.com> Fri, 01 April 2011 14:46 UTC

Return-Path: <dzonatas@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 C73FD3A687B for <vwrap@core3.amsl.com>; Fri, 1 Apr 2011 07:46:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.537
X-Spam-Level:
X-Spam-Status: No, score=-3.537 tagged_above=-999 required=5 tests=[AWL=0.062, 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 MMMz4pR9YPrI for <vwrap@core3.amsl.com>; Fri, 1 Apr 2011 07:46:02 -0700 (PDT)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 783703A686E for <vwrap@ietf.org>; Fri, 1 Apr 2011 07:46:02 -0700 (PDT)
Received: by gyf3 with SMTP id 3so1624306gyf.31 for <vwrap@ietf.org>; Fri, 01 Apr 2011 07:47:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=KDkcqpF3eIP+vTjs58eM80Y/2CCMTenelqclABHcAII=; b=QELsU0C9iHFRqJPWJbiHZTrQq15PPAL7NQQLpXFsJ6333nM9q77U70Z8w86Vd16RQ9 +uUUwd0MXm9HBgZcZqSJ/ZvAlTZRr3OIDuJn1W0PGOjrU0/zJ3ee++dq2YdbpjrXJREg JrmCb+CqhOsjMw1ja2Pw3LVpKzXBFTWHAqIEM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=NYRqoiOq2DzMy77mVn99W+R4Ph0qn8M1KpzqMKacRAKPWkhKUMEuL3YBP8DtKEB3nq WYRAzYix/QgBQumSmhNQDHt3Uu6P5KVvRaqDFb79KJYq9MQxVW1mXiR/5Hwk02ESxqG3 vbNjwhpbdgEIn1J9QLwxr4Hb7GmZS23+1dgBM=
Received: by 10.43.45.7 with SMTP id ui7mr4964511icb.262.1301669262301; Fri, 01 Apr 2011 07:47:42 -0700 (PDT)
Received: from [192.168.0.50] (adsl-71-137-195-251.dsl.scrm01.pacbell.net [71.137.195.251]) by mx.google.com with ESMTPS id wo15sm1356542icb.4.2011.04.01.07.47.38 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 Apr 2011 07:47:39 -0700 (PDT)
Message-ID: <4D95E5B6.90103@gmail.com>
Date: Fri, 01 Apr 2011 07:48:22 -0700
From: Dzonatas Sol <dzonatas@gmail.com>
User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329)
MIME-Version: 1.0
To: Morgaine <morgaine.dinova@googlemail.com>
References: <4D93E82C.7060503@gmail.com> <AANLkTinH2vz+HXTs2j60D2S4BsBH0uT=eG1kTnwBctfJ@mail.gmail.com> <4D949BFB.1010804@gmail.com> <AANLkTi=y3nSCw=nFVn0B0Q-6twov_Vq9MgZPrYC51YgO@mail.gmail.com> <1301591963.12359.53.camel@mdickson-hplinux> <AANLkTikRNuZ+X039tg0E4HTmFRZb6nqdtZaDOx2VSCj8@mail.gmail.com>
In-Reply-To: <AANLkTikRNuZ+X039tg0E4HTmFRZb6nqdtZaDOx2VSCj8@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: vwrap@ietf.org
Subject: Re: [vwrap] Conditioners and refineries
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: Fri, 01 Apr 2011 14:46:03 -0000

Much of the discussion is actually implemented, already (somehow). What 
"you" want, however, seems to be to have some LL-employee/OpenSim-dev to 
rewrite, reauthorize, reinvent, and bloat the monolithic client or add 
redundant capabilities on the simulators as some means to state what is 
official in VWRAP. None of that needs to happen, and please don't give 
the appearance that "we" need to beg any of them for implementation 
(especially, to tally some vote). Remember that the 
user-end/front-end/graphics-client is the one doing the real work. The 
simulator still exists as a router due to legacy reasons, so there is 
really no need to rely on LL sims or Opensim to implement any of this. 
(I'm sure backwards compatible is ideal.) The only exception is "domains".

No need to leverage the weight of storage over implementation. The ideal 
word is "cohesion" of various implementations...  not rewrite. Any 
rewrite or customization of implementations in any company is that 
company's business, not ours. Your assumption of what is in our "grasp" 
is in error because you assumed it in only part of LL or such 
reverse-engineered simulator, and there is no need for this sympathy 
here unless you're tried to win points with them somehow.

Win points here... not there...

Morgaine wrote:
 > That is incorrect.  IETF drafts are not promoted to Internet 
standards unless they have implementations --- again, the Mission 
Statement is worth reading.  "*Rough consensus and running code*" is a 
cardinal principle highlighted in BCP 95.  Since we do not have the 
power to test our ideas within Second Life, but only within open source 
frameworks like Opensim, SL compatibility is beyond our reach until such 
a time as Linden Lab provides the required test implementation.  In the 
absence of that, only Opensim and/or realXtend compatibility is within 
our grasp because we can add the "running code" there ourselves.

-- 
--- https://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant