Re: [mmox] MMOX: Strawman scope/goals/approach
Gareth Nelson <gareth@litesim.com> Thu, 26 February 2009 21:35 UTC
Return-Path: <gareth@litesim.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 9E4093A6807; Thu, 26 Feb 2009 13:35:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.971
X-Spam-Level:
X-Spam-Status: No, score=-1.971 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 Q13gVmRTQE8G; Thu, 26 Feb 2009 13:35:10 -0800 (PST)
Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.231]) by core3.amsl.com (Postfix) with ESMTP id 429A03A6C0A; Thu, 26 Feb 2009 13:35:10 -0800 (PST)
Received: by rv-out-0506.google.com with SMTP id l9so659714rvb.49 for <multiple recipients>; Thu, 26 Feb 2009 13:35:32 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.157.5 with SMTP id f5mr831452rve.122.1235684131912; Thu, 26 Feb 2009 13:35:31 -0800 (PST)
In-Reply-To: <OF7F32322B.61DEE52B-ON85257567.00564FEE-85257567.00585420@us.ibm.com>
References: <ebe4d1860902240729x5e86306bpd0950b05c3a11f28@mail.gmail.com> <OF7F32322B.61DEE52B-ON85257567.00564FEE-85257567.00585420@us.ibm.com>
Date: Thu, 26 Feb 2009 21:35:31 +0000
Message-ID: <61dbdd7d0902261335q608ee9ferc083fdffa87071ed@mail.gmail.com>
From: Gareth Nelson <gareth@litesim.com>
To: David W Levine <dwl@us.ibm.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: mmox-bounces@ietf.org, mmox@ietf.org
Subject: Re: [mmox] MMOX: Strawman scope/goals/approach
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: Thu, 26 Feb 2009 21:35:11 -0000
Well, I promised i'd give my thoughts on the list, so here they are: > I am attaching the input as a .txt and a (sigh) Microsoft word document. I > am also posting it in line as plan text. (tho ugly, I'll work on that for > future versions) A word document about a proposal for discussions of open standards. That's priceless > Specifications do not advance in the IETF in the absence of > demonstrated interoperability based on running code. This is a good thing(tm), and we should also discuss what languages any code should be produced in. My vote is for python and C. > I take MMOX as Massively MultiParty Online eXperiences (Since Meadbh didn't > define > X, we all get a shot at it) Lets take this one bit at a time. Massively, as > in experiences > intended to be shared by tens, hundreds, thousands, and over time, a > significant fraction > of the interne community. Online, focusing our attention on the concurrent > shared portion > of the experiences and eXperience as a shorthand for (Games, Applications > and shared > experiences.) One thing I would immediately point out is that though I can see how games are relevant (after all, MMORPGs for example are just huge virtual worlds with game rules thrown in), I fail to see how networked applications of a generic type are relevant. For example, if I use multiuser GNU screen, are we going to discuss interop so I can teleport from my screen session to SL? This is obviously quite nonsensical, and is an extreme case, but I must ask "where is the line drawn?" Practically everything people do online is "multiuser", and lots of things are "massively multiuser" - look at any big site such as wikipedia for example. > The group's name and remit is intentionally broad, focused on a general set > of Games and > Applications, not any single game, application or experience. The group's > roots, and > interests are largely, but not exclusively shaped by Virtual Worlds, > including MMO > games, Virtual worlds, Collaboration and Simulation Environments and shared > online > streaming environments. Examples of these platforms include, but are not > limited to > World Of Warcaft, ProtonSphere, Eve Online, Forterra's OLIVE platform, Club > Penguin, Linden Lab's Second Life, IMVU, There.com, Croquet, > OpenSimulator.org, > Weblins. Tiny nitpicking point - did you mean webkins, the virtual world for kids with the cute little pets and serial codes from toys? As for "shared online streaming environments", I presume this means any kind of interaction where people are streaming "something" such as video, audio or 3D stuff? If so, would this not also include stuff such as IRC? See where i'm going, we don't want "one working group to rule them all". > The common thread across all of these environments is a concurrent shared > experience, > often, but not exclusively rendered in a three dimensional space. Here's > one attempt to > scope what these environment share: > > 1. One or more virtual spaces > 2. A set of users > 3. A representation of the users projected into the space > 4. A shared experience of the events in the space projected back to > all the users > currently in the space. (Text, Voice, and the results of > actions) This mailing list could be considered a virtual space, as could a forum or an IRC channel. > Many of these environments will also include one or more of: > > 5. Objects which can be dynamically created and modified to form part > of the > space's setting > 6. Persistent state in the virtual space(s) > 7. Mechanisms to associate external streams of media with portions of > the > immersive space > 8. Mechanisms to run scripted behaviors in the space > 9. Simulated physics and behavior of objects and projected users in > the spaace > 10. Mechanisms for users to move from one virtual space to another > (by hand off > between regions implicitly, or by explicit user request > (teleport) > 11. Libraries of material the users can add to the space > 12. Mechanisms for users which are not in a common virtual space to > interact with > each other in some form (be aware of each other's locations > and online status, > message each other, etc) Shameless self-plug, have I talked to you about GMMP? Each channel in GMMP has a set of "channel objects" which contain persistent state. It's meant as an abstraction of any virtual world or any other internet protocol in such a way that you could visualise any arbitary protocol as a virtual world. It's a project i've been working on-and-off on for the past 1.5 years and I have some draft specs about 30% done. > Note I've very carefully avoided using most of the common words for the > shared > experience. We often speak of Simulators, Avatars, Regions, Assets and so > forth, for the > moment, I'm going to keep those terms off the table to think about the > problem in its > more general form. Sensible idea :) Though longterm we do need to agree on terminology. I suggest "location", "space" or "scene" instead of "region", with "avatar" and "assets" still being very neutral. > Note that I'm also very consciously taking a minimal base with optional > features > approach to describing the space. This allows us to focus on the core > overlapping > features, and then a set of services which add to this core. Think about how > these goals > and solutions could be applied to collaborative spaces such as Wikis, Micro > blogging > streams and collaborative desktop and application environments. I'm repeating myself, but I think it's a bad idea to go into any multiuser collaborative environments with this group. We can't reasonably hold a remit that large. Ironically in limiting your specifications of the problem space, you're making it HUGE. > Interoperability is not about defining the one true system which satisfies > these goals. > Interoperability is about making multiple existing implementation > interoperate by the use > of standards we define. Agreed - I think everyone on this list will agree with that one I'll continue commenting in another post
- [mmox] Requirements for new xxSD specification Catherine Pfeffer
- [mmox] MMOX: Strawman scope/goals/approach David W Levine
- Re: [mmox] MMOX: Strawman scope/goals/approach Jon Watte
- Re: [mmox] Requirements for new xxSD specification Lisa Dusseault
- Re: [mmox] MMOX: Strawman scope/goals/approach Mark P. McCahill
- Re: [mmox] MMOX: Strawman scope/goals/approach Christian Scholz
- Re: [mmox] MMOX: Strawman scope/goals/approach Meadhbh Hamrick (Infinity)
- Re: [mmox] MMOX: Strawman scope/goals/approach Christian Scholz
- Re: [mmox] MMOX: Strawman scope/goals/approach Gareth Nelson
- Re: [mmox] MMOX: Strawman scope/goals/approach Jon Watte
- Re: [mmox] MMOX: Strawman scope/goals/approach Lawson English
- Re: [mmox] MMOX: Strawman scope/goals/approach Meadhbh Hamrick (Infinity)
- Re: [mmox] MMOX: Strawman scope/goals/approach Gareth Nelson
- Re: [mmox] MMOX: Strawman scope/goals/approach Meadhbh Hamrick (Infinity)
- Re: [mmox] MMOX: Strawman scope/goals/approach David W Levine
- Re: [mmox] MMOX: Strawman scope/goals/approach Ryan McDougall