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