Re: [mmox] A few assumptions if I may
Kajikawa Jeremy <belxjander@gmail.com> Wed, 18 February 2009 14:31 UTC
Return-Path: <belxjander@gmail.com>
X-Original-To: mmox@core3.amsl.com
Delivered-To: mmox@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D86DC3A6C66 for <mmox@core3.amsl.com>; Wed, 18 Feb 2009 06:31:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.203
X-Spam-Level:
X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[AWL=-0.204, BAYES_00=-2.599, J_CHICKENPOX_41=0.6]
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 6ybbsmTseQPu for <mmox@core3.amsl.com>; Wed, 18 Feb 2009 06:31:21 -0800 (PST)
Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.226]) by core3.amsl.com (Postfix) with ESMTP id EEF413A699A for <mmox@ietf.org>; Wed, 18 Feb 2009 06:31:20 -0800 (PST)
Received: by rv-out-0506.google.com with SMTP id l9so2437069rvb.49 for <mmox@ietf.org>; Wed, 18 Feb 2009 06:31:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:in-reply-to :references:disposition-notification-to:content-type:date:message-id :mime-version:x-mailer; bh=r7WC1n+jgWbgb5XLKfcqF/9Q4CoHioJZr0GBtGddag8=; b=oB/3x2/xnYxWIZWvrIP6VKAosFyKWTjAvWPOT8MCW7i1gQJXOOFsFSrulfcoYh3rbq lRqtU1DjtoRt6YLu61cm1t9XDuD2t1HW4cRDilNaMn9NlVxHkqhynhFQ3JDWKyNMXcN8 NiPgqCshzpfj3j1LepUl6ib2/kTWoUDROsPsQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:in-reply-to:references:disposition-notification-to :content-type:date:message-id:mime-version:x-mailer; b=NYhnr8fE33vrN47UzDsJhzO4TqX53YcHrxqlKh3pqe4yFa5qtZVRgkaPpq4Wuzy7g9 L1jpK3shVWCiIyeR9llm0SIz1rhBleVX3xt0R2IeVsFTQ3AYCz9lVPDHnRkGUkzVvWLz FR7ahYgvA9UHcRRrYcT923YiNBsRKvvo9oLII=
Received: by 10.140.164.6 with SMTP id m6mr4004954rve.29.1234967492468; Wed, 18 Feb 2009 06:31:32 -0800 (PST)
Received: from ?10.2.1.3? (p1012-ipbfp305tottori.tottori.ocn.ne.jp [114.155.20.12]) by mx.google.com with ESMTPS id g31sm16967383rvb.7.2009.02.18.06.31.31 (version=SSLv3 cipher=RC4-MD5); Wed, 18 Feb 2009 06:31:31 -0800 (PST)
From: Kajikawa Jeremy <belxjander@gmail.com>
To: "mmox@ietf.org" <mmox@ietf.org>
In-Reply-To: <61dbdd7d0902171801t16617ae5n59e170d2a31235ba@mail.gmail.com>
References: <61dbdd7d0902171801t16617ae5n59e170d2a31235ba@mail.gmail.com>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-C6vUEapDNy6dfwqfM09p"
Date: Wed, 18 Feb 2009 23:26:15 +0900
Message-Id: <1234967175.7560.30.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.3.1
Subject: Re: [mmox] A few assumptions if I may
X-BeenThere: mmox@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Massively Multi-participant Online Games and Applications <mmox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mmox>, <mailto:mmox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmox>
List-Post: <mailto:mmox@ietf.org>
List-Help: <mailto:mmox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmox>, <mailto:mmox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Feb 2009 14:31:21 -0000
I agree with gareth about having a required "core" and then working from that and I am also in agreement about needing *neutral* or open standards, not the limited and limiting use of stuff like .NET remoting which I am aware of has a limit with regards transfer of non-public data being non remote capable. speaking of this however also opens up the use of C# and .NET runtime as a limitation since no one outside microsoft actually has ownership of anything in the code using it. and a true server will work with one core protocol and allow for extensions, apache was built similarly and I can already expand that with existing scripting for provision of the non-region services in SL. I personally see OpenID and OAuth being usable components towards an open grid infrastructure that is easily maintained. And see dependence on the .NET runtime as sitting with a permanent hammer ready to drop at any time. (loss of msft, what happens to that runtime?, new owner?) Also Im finding myself primarily hamstrung in my own work due to non-code issues, and the real world need for paying work that actually pays on time. if anyone wants to hire me to actually get things done quicker... *please do so* Im not knowing the "Snow Crash" book(s?) that are referenced by the OpenSIM group, Ive also tried to play with the libSecondLife before the LibOpenMetaverse naming. (very unsuccessfully) and I am currently working with python which is letting me get somewhere. I get the feeling like I will be burning braincells before I actually get to be at any of the "real" discussions or get a decent handle on the vocabulary terms used by this group when meetings happen (Im in Japan and have real life keeping me out of sync with "Office hours" as it is). Sincerely, Jeremy Kajikawa (Real) (Belxjander Serechai (Internet)) ( Freija Yoshikawa (Internet@SecondLife+OpenSIM)) On Wed, 2009-02-18 at 02:01 +0000, Gareth Nelson wrote: > 1 - We need an absolute basic core of identity > 2 - We need a modular design where extra services (simple stuff such > as chat and inventory) are bolted onto that core with mechanisms such > as optional caps URLs (man I love caps) > 3 - On the "intellectual property" issue, we should take the view that > if a particular system is serving up an asset, it is authorised to do > so - in other words, if you can do (for example) an HTTP GET on an > object, it may come with permissions flags in the metadata, but we > should enforce these flags only on end systems - clients, inventory > servers, asset servers and simulators - this simplifies the legal > issues and pushes liability to where it belongs, with the users > 4 - This should be obvious, but anything intended for an actual RFC > should be 100% neutral of any particular virtual world/MMO or > platform, so stuff like the .NET remoting in opensim (a pet peeve of > mine) is out > 5 - Binary protocols should be used whenever efficiency is important, > but designed in an extensible fashion such that one particular packet > type once defined will always mean the same thing and systems > implementing such protocols can rely on a core set of messages always > being available with graceful degradation for anything outside of this > core - we need not see the whole world through HTTP-tinted glasses > _______________________________________________ > mmox mailing list > mmox@ietf.org > https://www.ietf.org/mailman/listinfo/mmox
- [mmox] A few assumptions if I may Gareth Nelson
- Re: [mmox] A few assumptions if I may Kajikawa Jeremy