Re: [vwrap] xml-org-ietf-vwrap- Re: Working Draft: SNOW-375

Dzonatas Sol <dzonatas@gmail.com> Thu, 05 August 2010 00: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 067513A6956 for <vwrap@core3.amsl.com>; Wed, 4 Aug 2010 17:46:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.165
X-Spam-Level:
X-Spam-Status: No, score=-1.165 tagged_above=-999 required=5 tests=[AWL=-0.425, BAYES_20=-0.74]
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 urRT33jbGSqZ for <vwrap@core3.amsl.com>; Wed, 4 Aug 2010 17:46:49 -0700 (PDT)
Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id A6E2B3A6873 for <vwrap@ietf.org>; Wed, 4 Aug 2010 17:46:49 -0700 (PDT)
Received: by pvd12 with SMTP id 12so2559054pvd.31 for <vwrap@ietf.org>; Wed, 04 Aug 2010 17:47:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=+QFE2o0ee3VUtl+jrdVPzZHfJC/H92dlMZTZr2JplVE=; b=uxnvABZWnSL2pTp0+BsooMfiKYOMQZ385BZC1OnfIyshyLpYBaauDTZiyQOvWKylqO MqAZBogaIcFNrWVeAAz4JVcGPgPs7ZOiWHqxHxAOv91UXfNnmyVEbEGWbxIRnjeopFr7 4tNGYcawfkB6npgOyZIbA77OOHZ7F0PFX9T5Q=
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=chzf8LZRU2GPpM704/G3G+Kr96K290uNIeOMPcuTrC9ZhbTjCMH2/WxM2xQN/p/0r4 HBqc7ZxHmBQdapGAiOwbSHgewVl21SwWquC6VD7/cLMTN4Y+1DPlISNvcVPTpLNvhDdt +VgNyM+3855wv3Y3EYdsh8FgCUsOB4A9AVClI=
Received: by 10.142.171.9 with SMTP id t9mr8412871wfe.320.1280969239670; Wed, 04 Aug 2010 17:47:19 -0700 (PDT)
Received: from [192.168.0.50] (adsl-68-124-103-250.dsl.scrm01.pacbell.net [68.124.103.250]) by mx.google.com with ESMTPS id w27sm11176722wfd.17.2010.08.04.17.47.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 04 Aug 2010 17:47:17 -0700 (PDT)
Message-ID: <4C5A0D0F.6070900@gmail.com>
Date: Wed, 04 Aug 2010 17:59:59 -0700
From: Dzonatas Sol <dzonatas@gmail.com>
User-Agent: Mozilla-Thunderbird 2.0.0.24 (X11/20100329)
MIME-Version: 1.0
To: "Dickson, Mike (ISS Software)" <mike.dickson@hp.com>
References: <4C542CAC.1090301@gmail.com> <AANLkTinLVdcwHGWWuXztN6EnBA5jL56iaRvX9pR54vOX@mail.gmail.com> <4C572A6E.8070905@gmail.com> <AANLkTik1ukKWhNcJ0TgWfREf0YCd_oLutcxk8_j4b+=e@mail.gmail.com> <4C573C43.5060905@gmail.com> <4C58443F.80502@gmail.com> <4C584C52.6040309@gmail.com> <4C5967C6.4080501@gmail.com> <4646639E08F58B42836FAC24C94624DD85E085CDAE@GVW0433EXB.americas.hpqcorp.net>
In-Reply-To: <4646639E08F58B42836FAC24C94624DD85E085CDAE@GVW0433EXB.americas.hpqcorp.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "vwrap@ietf.org" <vwrap@ietf.org>
Subject: Re: [vwrap] xml-org-ietf-vwrap- Re: Working Draft: SNOW-375
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, 05 Aug 2010 00:46:51 -0000

Dickson, Mike (ISS Software) wrote:
> How does it relate to the protocol specs?
>   


The protocol needs to be aware of springboard functions, which are only 
used for organizational needs. As functions are implemented in the 
subsystem and accessible from user land, there has always been an 
increased chance they'll be used as a standard. A review of the 
use-cases, we can select a few for AOT mode, and which ones fallback to 
user land. This then relates the a newer concept of the shell.

I'm familiar with the usual outcomes that have tried that and then tried 
to undo it. Those of us that have done it and have kept it stable over 
the years or have no need to change it know where we started. Our 
methods aren't probably different, so there is again another increased 
chance to rebuild each other.

There is no way to simplify synchronization and atomicity in the 
protocol itself, yet we can, for example, start with a ReSTful way to 
handle mime-types as resources and stress that the media matches a 
certain format, XML. From here, the protocol can present itself in 
timeslices, banked-memory schemes, or micro-kernels. There is also the 
lockless cache method, yet this method is best for the kernel developers 
to decide if the subsystem is allowed such technique. I've tested a 
combination of these schemes already. I cannot release specifics, yet 
the code is open source. They each add to performance, so there is no 
best method. I'm not gonna taint the protocol, yet the trust level still 
amazes me. I would call the work a peacemaker.

I'll admit, I showed some professors and it blew their mind when I told 
them a full stateful system transfer occurred in less than 100 cycles -- 
but I unloaded immediately after the proof because I knew they couldn't 
explain what just happened. Earned Highest Honors. I didn't do the hard 
work, I just added the cache and buffered the events to keep the system 
responsive. Time skew became more common, and it provided a way to work 
on it. I optimized it further on context, yet I never published that code.

I always kept in mind... should we...with no concept of context... as a 
subsystem? I just create the pen...

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