Re: [mmox] 3-world OGP interop scenario

Charles Krinke <charles.krinke@gmail.com> Wed, 18 March 2009 15:55 UTC

Return-Path: <charles.krinke@gmail.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 792493A6817 for <mmox@core3.amsl.com>; Wed, 18 Mar 2009 08:55:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 m70m05jI-j0n for <mmox@core3.amsl.com>; Wed, 18 Mar 2009 08:55:41 -0700 (PDT)
Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by core3.amsl.com (Postfix) with ESMTP id EFC133A67CC for <mmox@ietf.org>; Wed, 18 Mar 2009 08:55:40 -0700 (PDT)
Received: by qw-out-2122.google.com with SMTP id 9so89298qwb.31 for <mmox@ietf.org>; Wed, 18 Mar 2009 08:56:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=iKxp8ZGX5boSYPFKH4iFQ/wRS4PMQvw8dfa/iE0ceBc=; b=i/bL3md4yqztaYGukNVkXmU0LyCEy9AP8PymH7Eygxkhv890RGozCdFA5pySMWEx2I SRwSRGdwOmHIQFvhesxJ7WkACLUzs4O4V0vPpSg3Cxno+VQNt4xtK/NxpEbcZZQO/fNM zyL1CIAhiJrIIe70v68QxQhhQPT04E+z5WD5k=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=qlCOWSnWOqFiA6id0DqqAMOnQiBaifSbR3im+goevVLGioRWW/6PxKHGTXy8vCeYEE jodcFvRE67UxT+gA5s50F3Soe/4pmEcwQk9B9fDTfCqMKnLX2u+JAA5O6Z3FFQ6iBPip iAqathyMHoc/rQcIkovcnPjSTIRoamtCNFCvg=
MIME-Version: 1.0
Received: by 10.220.72.209 with SMTP id n17mr974610vcj.44.1237391784918; Wed, 18 Mar 2009 08:56:24 -0700 (PDT)
In-Reply-To: <e0b04bba0903180711u625a383dqe91bee4cc7918e69@mail.gmail.com>
References: <e0b04bba0903120735s5311a922ybbc40a30433166a3@mail.gmail.com> <3B6FBE24-68BA-4E23-908F-E7ED0BB5B73B@lindenlab.com> <e0b04bba0903180711u625a383dqe91bee4cc7918e69@mail.gmail.com>
Date: Wed, 18 Mar 2009 07:56:24 -0800
Message-ID: <f0b9e3410903180856uc2d4c58lc363a6b3b63b3f4f@mail.gmail.com>
From: Charles Krinke <charles.krinke@gmail.com>
To: Morgaine <morgaine.dinova@googlemail.com>
Content-Type: multipart/alternative; boundary="001636284f3cc9c05c046566b950"
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 15:55:42 -0000

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