Re: [mmox] what does it mean to be interoperable?

Christian Scholz <cs@comlounge.net> Thu, 26 February 2009 23:15 UTC

Return-Path: <cs@comlounge.net>
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 A3CCE3A6A75 for <mmox@core3.amsl.com>; Thu, 26 Feb 2009 15:15:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level:
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599]
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 zJgnEP8mT8h0 for <mmox@core3.amsl.com>; Thu, 26 Feb 2009 15:15:07 -0800 (PST)
Received: from post.comlounge.net (post.comlounge.net [85.214.59.142]) by core3.amsl.com (Postfix) with ESMTP id 306073A68CD for <mmox@ietf.org>; Thu, 26 Feb 2009 15:15:07 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by post.comlounge.net (Postfix) with ESMTP id 77F811CE03D5; Fri, 27 Feb 2009 00:15:28 +0100 (CET)
Received: from post.comlounge.net ([127.0.0.1]) by localhost (h1346004.stratoserver.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tf2abtSueNEZ; Fri, 27 Feb 2009 00:15:27 +0100 (CET)
Received: from [192.168.2.101] (pD9EBC236.dip.t-dialin.net [217.235.194.54]) by post.comlounge.net (Postfix) with ESMTP id 534EA1CE0001; Fri, 27 Feb 2009 00:15:27 +0100 (CET)
Message-ID: <49A7228F.1070902@comlounge.net>
Date: Fri, 27 Feb 2009 00:15:27 +0100
From: Christian Scholz <cs@comlounge.net>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: "Meadhbh Hamrick (Infinity)" <infinity@lindenlab.com>
References: <228D0A40-F63F-4564-9200-0FF543902FD4@lindenlab.com>
In-Reply-To: <228D0A40-F63F-4564-9200-0FF543902FD4@lindenlab.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: mmox@ietf.org
Subject: Re: [mmox] what does it mean to be interoperable?
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 23:15:11 -0000

I just wonder if you not first need to define what a virtual world is as 
it seems to me a conglomeration of lots of concepts.

E.g. there is the whole social space which seems very similar in what's 
going on on the web and has many aspects to it already. There is also 
the 3D area which is about objects and how to transfer and display them, 
there are avatars, there are actual worlds and so on.

And I think some areas here might be easier to tackle (e.g. mostly 2D 
space) because there might be more common understanding already about 
this (and it's mostly HTML/HTTP based which is used by everybody and 
thus makes things easier).

On the 3D part the question is how to partition further.

I think for different sub-protocols we might choose different variants 
of the choices below.

But one is maybe for sure and that is that 1) and 2) are out for not 
only VWs but for basically everything.

But if you exchange "virtual worlds" by some sub-area then there might 
actually be a unified client for these (again most likely in the social 
space where it can be a web browser). For the full stack it's most 
likely no unified client because I doubt that we all can find one 
solution which fits us all (in all eternity).

So it probably will come down to 5. Maybe some stuff is bridgable with 
not too much effort, then this might be an option for 6 but I have too 
little understanding of all things to really be able to speculate about 
that.

-- Christian



Meadhbh Hamrick (Infinity) schrieb:
> so it seems clear we all have different ideas of what it means to be 
> interoperable.
> 
> i thought i might try to define a couple of the definitions i think i've 
> seen people use:
> 
> 1. interoperability means all virtual worlds, wherever they are, may be 
> accessed via a single unified client.
> 
> 2. interoperability means all virtual worlds, wherever they are, use 
> precisely the same protocol(s) and all virtual worlds represent data in 
> formats understandable by all other virtual worlds, with a universal 
> client.
> 
> 3. interoperability means some virtual worlds may be accessed via a 
> single unified client.
> 
> 4. interoperability means some virtual worlds use precisely the same 
> protocol(s) and all virtual worlds represent data in formats 
> understandable by all other virtual worlds, without a universal client.
> 
> 5. interoperability means some virtual worlds use some of the same 
> protocols, without a universal client
> 
> 6. interoperability means the "model" is the same, but with different 
> protocols that may be bridged with protocol gateways.
> 
> it seems to me that many of us are using different descriptions for the 
> word "interoperable" and it's causing mild discord and at least a couple 
> instances of us talking past each other.
> 
> personally.. i'm kind of interested in option 5. it has the benefit of 
> producing a protocol that is identifiable by routers, network management 
> software, etc. it also provides a "slowly moving target" for open source 
> developers (as opposed to the "fast moving target" of linden's existing 
> protocol(s)). by making it public, VW operators can choose whether or 
> not they wish to implement it. it also doesn't require VW operators to 
> implement it (as if we could anyway) and it allows VW operators to avoid 
> having to test interoperability with every other virtual world.
> 
> but it's not without drawbacks... this model can lead to a "MOSS-like" 
> environment. (for those of you who don't remember MOSS or MIME Object(?) 
> Security Services... it was a response to the drawbacks of PEM (privacy 
> enhanced mail) which had a relative paucity of encryption options. but 
> IMHO, MOSS introduced so many options that it was VERY easy for two 
> implementations to adhere to the spec, but not actually be interoperable.)
> 
> so... i recommend that if we (as a group) wanted to pursue option-5.. we 
> also explicitly define what goes in an "interoperability profile." that 
> way you could get the benefit of having a relatively stable protocol 
> that could be targeted by open source developers which could be used by 
> VW operators to help make client / server apps.
> 
> VW operators could publish their "interoperability profile" to tell 
> people who wanted to build tools, extra services, or interoperable 
> worlds what options would be available and how they would work.
> 
> -cheers
> -m
> _______________________________________________
> mmox mailing list
> mmox@ietf.org
> https://www.ietf.org/mailman/listinfo/mmox


-- 
Christian Scholz
Blog: http://mrtopf.de/blog
Company: http://comlounge.net
Podcasts: http://datawithoutborders.net, http://openweb-podcast.de