Re: [mmox] 3-world OGP interop scenario

Morgaine <morgaine.dinova@googlemail.com> Wed, 18 March 2009 17:37 UTC

Return-Path: <morgaine.dinova@googlemail.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 9EE5528C132 for <mmox@core3.amsl.com>; Wed, 18 Mar 2009 10:37:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.592
X-Spam-Level:
X-Spam-Status: No, score=-1.592 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_54=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 xMRUbcoDN9LL for <mmox@core3.amsl.com>; Wed, 18 Mar 2009 10:37:32 -0700 (PDT)
Received: from mail-ew0-f165.google.com (mail-ew0-f165.google.com [209.85.219.165]) by core3.amsl.com (Postfix) with ESMTP id 86BEF3A6B48 for <mmox@ietf.org>; Wed, 18 Mar 2009 10:37:31 -0700 (PDT)
Received: by ewy9 with SMTP id 9so130307ewy.37 for <mmox@ietf.org>; Wed, 18 Mar 2009 10:38:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=ZbPOSbB8bmgSzIHj0x36hASUdsJvfvWbmdkGcy5N5Uc=; b=B89eDeKqrsl9GHjrR8qz6mbpE25EAj7Xg+xDmK80Id59l/LIlB2uYv5XSg/f9n1ASa 7Hds/5KLbywKidEFdqKW3o5ZY2vEgktXNYN9hH/oVyVIt/CIdbC0iU31IwcniRqope5g SkM4RlDHSURjunl1N4nzIfym0VmsD3b0zbNrQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=OwphlmMq71UKgEF8Erlzy+HOAHigr0zDt4F9RKb5TaP0Br4aycGAoz8tDPTWdQN2wY p6RGHw0v/XAXKjTRvc0McpgE6YJ+gKEbCETC4XQAnYAeIwcTq1i1oX+zR2Q+0q3Shw45 6O8TeOqrb/HBNVKSzp7CU2Yg0ACSREzkdCGMA=
MIME-Version: 1.0
Received: by 10.210.141.17 with SMTP id o17mr952854ebd.79.1237397895077; Wed, 18 Mar 2009 10:38:15 -0700 (PDT)
In-Reply-To: <f0b9e3410903180856uc2d4c58lc363a6b3b63b3f4f@mail.gmail.com>
References: <e0b04bba0903120735s5311a922ybbc40a30433166a3@mail.gmail.com> <3B6FBE24-68BA-4E23-908F-E7ED0BB5B73B@lindenlab.com> <e0b04bba0903180711u625a383dqe91bee4cc7918e69@mail.gmail.com> <f0b9e3410903180856uc2d4c58lc363a6b3b63b3f4f@mail.gmail.com>
Date: Wed, 18 Mar 2009 17:38:14 +0000
Message-ID: <e0b04bba0903181038r26724ac1m10eeba33ae17e26c@mail.gmail.com>
From: Morgaine <morgaine.dinova@googlemail.com>
To: Charles Krinke <charles.krinke@gmail.com>
Content-Type: multipart/alternative; boundary="0015174bf0f8fb5fe70465682587"
Cc: MMOX-IETF <mmox@ietf.org>
Subject: Re: [mmox] 3-world OGP interop scenario
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 Mar 2009 17:37:33 -0000

I agree completely Charles.  Few things are more relevant to interop between
worlds than actually "moving" (in the widest possible sense) between them.

Teleports, direct region adjacency, gateways, wormholes, and joint
visualization of shared spaces are all within our scope.  And to ensure that
it doesn't fall off our radar, I would like to mention Croquet's portals
between worlds (I don't know their actual name in Croquet) which allow you
to see a remote world as if through a mirror with full perspective, before
hopping through it.

Our protocol work needs to support all of these concepts and more.
Fortunately, that is easy to do, simply by focusing not on their in-world
representations but on their underlying requirements.  These are minimal:


   - Access to world data decoupled from any notion of an agent or avatar
   travelling there (otherwise you would never be able to see what's on the
   other side of a portal or boundary before travelling).
   - World transitions decoupled from any geographical layout or topology
   (otherwise you would never be able to teleport by landmark or address).


We don't mandate any specific *policy* of course, so a particular world may
allow only one particular method of entry.  The protocol itself however does
need to provide the above two functions as *decoupled mechanisms*, otherwise
more general movement between worlds is blocked.


Morgaine.








On Wed, Mar 18, 2009 at 3:56 PM, Charles Krinke <charles.krinke@gmail.com>wrote:

> One thing that sticks in my mind is experiencing some of the script-based
> HyperGrid teleports on OSGrid recently.
>
> Since those are using llHTTPRequest/http_response, it seems to me that
> ensuring that whatever is adopted by this group considers enough flexibility
> to allow folks to script the opening of gateways or wormholes or whatever to
> other virtual worlds yet to be heard from.
>
> Having enough flexibility so that a script-type of language using simple
> http calls and responses seems like a powerful and compelling feature to
> ensure we dont loose.
>
> Charles Krinke
> OpenSim Core Developer
> OSGrid Director
>
> 2009/3/18 Morgaine <morgaine.dinova@googlemail.com>
>
> On Tue, Mar 17, 2009 at 11:24 PM, Mark Lentczner <markl@lindenlab.com>wrote:
>>
>>>
>>> Fundamentally - I think the scenario that Morgaine started this thread
>>> with points to an architecture that what many people want and satisfies many
>>> use cases.
>>>
>>>
>>>
>> That's good to hear from you, Mark.  The 3-world scenario<http://www.ietf.org/mail-archive/web/mmox/current/msg01114.html>is deliberately simple, yet it captures the central goal of interop:   to
>> provide *users* with an interactive mashup composited out of elements
>> taken from multiple, diverse worlds.  Everything else is a means to that
>> end.
>>
>> In these few days remaining before the BoF and perhaps for a short while
>> after that, it is a key element of our work to define the problem space
>> (along with a few tentative solutions), since it is on that basis that a WG
>> will be approved or denied.
>>
>> I believe that the given scenario defines the core of the *problem space*with good coverage, although of course not total coverage.  Very
>> importantly, it says NOTHING about the *solution space*:  anyone who is
>> strongly averse to adding MMOX protocol handling to their clients should
>> note that the scenario does NOT say that A1's client has connected to B nor
>> to C during the avatar's virtual travels to those worlds.  That would be a
>> solution-space detail.
>>
>> I hope that this can be a common denominator between us all.
>>
>>
>> Morgaine.
>>
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Mar 17, 2009 at 11:24 PM, Mark Lentczner <markl@lindenlab.com>wrote:
>>
>>> Do you seriously think it's a good idea to specify all the minutiae of
>>>> how a server and client interact, as a standard protocol?
>>>>
>>> Yes.
>>> Telnet, FTP, IMAP & 2822, HTTP & HTML, XMPP, to name a few past examples.
>>>
>>>  Including how GUI is tied to local and remote capabilities, how a scene
>>>> graph is constructed and animated, how version patching is done, how user
>>>> control is forwarded, etc?
>>>>
>>> Yes insofar as the semantics of the capabilities are defined, but not the
>>> precise UI.  HTML & CSS specify quite a bit about the semantics of the
>>> presentation - and often dictate quite precise presentation.  But browsers
>>> are pretty free to create GUI as they see fit.
>>> No to version patching. Updating the client is beyond the scope of the
>>> protocol.
>>>
>>>  And all that work, just to be able to show up in world B instead of
>>>> world A?
>>>>
>>> Yes.
>>>
>>>  What about objects you want to use cross worlds; are you saying you also
>>>> want to specify the exact runtime requirements for objects (scripting
>>>> language, physics interface, etc)?
>>>>
>>> Yes.
>>> 2822 & MIME, HTML & CSS & JavaScript, ODF to name a few past examples.
>>>
>>>  I believe that the real enabler of interop is to be able to merge the
>>>> simulations of different worlds
>>>>
>>> Ah - here we disagree.  I think this is a non-starter for the vast
>>> majority of users and use cases. Whereas I think users really care about
>>> using a single client, and a single virtual identity to roam the wide-open
>>> spaces of the metaverse.
>>>
>>>  So, if no users want to pay money for the convenience of not having to
>>>> install two separate clients, exactly why would any profit-seeking company
>>>> implement a second protocol in their client?
>>>>
>>> Is it just a convenience that you don't have to download and run a
>>> different browser-like client applications for your bank, for Netflix, for
>>> Wikipedia, and for Google? I am old-enough to remember an Internet where
>>> each of those would have been independent protocols, with independent
>>> clients. While I as a user consider the single, universal web browser of
>>> great value - and would pay for it (I own a retail copy of Netscape
>>> Navigator!) - every other segment of the computer industry benefits so
>>> greatly by this architecture, that the browser has become free.
>>>
>>> Fundamentally - I think the scenario that Morgaine started this thread
>>> with points to an architecture that what many people want and satisfies many
>>> use cases.
>>>
>>>        - Mark
>>>
>>> Mark Lentczner
>>> Sr. Systems Architect
>>> Technology Integration
>>> Linden Lab
>>>
>>> markl@lindenlab.com
>>>
>>> Zero Linden
>>> zero.linden@secondlife.com
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> mmox mailing list
>>> mmox@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mmox
>>>
>>
>>
>> _______________________________________________
>> mmox mailing list
>> mmox@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmox
>>
>>
>
>
> --
> Charles Krinke
> OpenSim Core Developer
> OSGrid Director
>