Re: [mmox] MMOX Progress tracking (Jon Watte)

"zedmaster" <zedmaster@zedrock.com> Thu, 12 March 2009 09:13 UTC

Return-Path: <zedmaster@zedrock.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 C68143A67CC for <mmox@core3.amsl.com>; Thu, 12 Mar 2009 02:13:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.649
X-Spam-Level:
X-Spam-Status: No, score=0.649 tagged_above=-999 required=5 tests=[AWL=-0.164, BAYES_00=-2.599, FAKE_REPLY_C=2.012, HELO_EQ_BLUEYON=1.4]
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 ut3pdre40A1f for <mmox@core3.amsl.com>; Thu, 12 Mar 2009 02:13:52 -0700 (PDT)
Received: from smtp-out2.blueyonder.co.uk (smtp-out2.blueyonder.co.uk [195.188.213.5]) by core3.amsl.com (Postfix) with ESMTP id 9EA2B3A6877 for <mmox@ietf.org>; Thu, 12 Mar 2009 02:13:52 -0700 (PDT)
Received: from [172.23.170.147] (helo=anti-virus03-10) by smtp-out2.blueyonder.co.uk with smtp (Exim 4.52) id 1Lhgzj-0006Za-Jz for mmox@ietf.org; Thu, 12 Mar 2009 09:14:27 +0000
Received: from [92.237.149.174] (helo=bumpydell) by asmtp-out6.blueyonder.co.uk with smtp (Exim 4.52) id 1Lhgzi-0005lV-Tu for mmox@ietf.org; Thu, 12 Mar 2009 09:14:27 +0000
Message-ID: <5409CEA96CD64A9E9B28D95FE723A452@bumpydell>
From: zedmaster <zedmaster@zedrock.com>
To: mmox@ietf.org
Date: Thu, 12 Mar 2009 09:14:25 -0000
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="response"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5512
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Subject: Re: [mmox] MMOX Progress tracking (Jon Watte)
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, 12 Mar 2009 09:13:53 -0000

Jon makes an excellent point here; true interop implies that there is no 
single world owner/vendor, but suggests that any world is made up from 
contributions from multiple sources.  Everything in the mail trail so far 
seems to be heading towards isolated worlds (islands) served by a common 
server-client protocol, between which a user might be able to teleport, but 
this isnt really going to help build the sort of detailed worlds that i 
think people are wanting.  All you will be able to do is hop beteween 
experiences - a bit like the "old" web model of hoppping between sites. 
Mashups have changed all that - people are now building sites which deliver 
an aggregated experience i.e. using webservices etc. they can pull together 
diverse sets of data and present something new, something the original sites 
couldnt do alone.

Imaging that I have access to some VR technology that can put immersive 
users (full motion tracking) into complex mechanical assemblies and let the 
user operate and interact with the items e.g. operate a back hoe on a JCB, 
or study the detailed assmembly instructions for an entire airliner.   I 
would like to deploy that technology to a shared world where others could 
come view my models; I wouldnt expect everyone to have access to the full 
body tracking, but i would like them to be able to walk around and touch and 
press buttons etc..

True interop to me implies that I could run the simulator which "owns" my 
mechanical entity, and I could do this wouthout needing to know or care how 
others get to view this; it doesnt matter to my simulation, as long as I get 
'standardised' inputs (telling me when someone touches something) and I get 
to send 'standard' outputs saying how the results of my simulation have 
changed.  I dont want to have to code my simulation in N different scripting 
languages for N different worlds - i just want to be able to register that 
my aeroplane is 'somewhere' in 3D space and let the worlds work out who sees 
it.

This model isnt new.  A number of the early networked VR systems (dvs, dive, 
simnet/dis)supported this federated model.  Some existing/upcoming systems 
(Sirikata is a good example) are proposing that this sort of federated 
architecture is going to be key in building really complex worlds.  It would 
be fantastic to see them contribute to this discussion.

Dare I ask the simple question here which is why not build on top of 
existing examples e.g. DIS/HLA?
If not directly extending them, learn from them and build something better.
-dirk


> ----- Original Message ----- 
>> Date: Wed, 11 Mar 2009 17:46:17 -0700
>> From: Jon Watte <jwatte@gmail.com>
>> Subject: Re: [mmox] MMOX Progress tracking
>
> .> I am claiming that a client/server protocol does not achieve virtual
>> world interop, because there is only one world involved in the 
>> connection. Thus, there is no interop between virtual worlds (plural). 
>> Thus, it's not applicable to the "vendor neutral virtual world 
>> interoperability" that is in the charter for this group, because, by 
>> necessity, only one vendor and one world is involved at a time. Let's 
>> call it scope control.
>>
>> Separately, as I keep having to repeat every week, because new people 
>> come to the list: I think that a standard client/server protocol solves a 
>> very small, uninteresting problem. It solves the problem of having to 
>> install two, three or four clients, which is a small problem. In fact, I 
>> doubt you could even get very many people to pay a single dollar for the 
>> convenience of not having to install two clients to be able to visit two 
>> different worlds (assuming versioning could be solved at all). It doesn't 
>> solve anything else -- specifically, if I want to be with person A, who 
>> is in virtual world A, and person B, who is in virtual world B, at the 
>> same time, a standardized server/client protocol makes no difference; I 
>> still have to choose one or the other. That is a problem we have now, 
>> have no good vendor neutral solution for, and need a standard for.
>>
>> If you want a standard for client/server connections that lets you stay 
>> within the same client while switching connection between different, 
>> independent worlds, just put a plugin in a browser, and write it in Flash 
>> or Java. The language and the browser is the standard; it can be done 
>> today (and has been done). I can, from my browser, easily surf on over to 
>> another site that uses a different flash/java plug-in, and connect to 
>> that other world, without losing my browser context. For all intents and 
>> purposes, this looks to the user as if "the same client" connects to 
>> those different worlds. The fact that very few implementors do that means 
>> that that kind of interop simply isn't that interesting.
>>
>> If you think it's valuable to have a client/server protocol standardized 
>> through the IETF, then you should do so within a group that is 
>> appropriately chartered. In my opinion, the MMOX charter is not 
>> appropriate for that at the current time (and, in my opinion, that's a 
>> good thing).
>>
>> Sincerely,
>>
>> jw
> .