Re: [mmox] 3-world OGP interop scenario

Morgaine <morgaine.dinova@googlemail.com> Wed, 18 March 2009 14:10 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 62D2F28C17E for <mmox@core3.amsl.com>; Wed, 18 Mar 2009 07:10:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.595
X-Spam-Level:
X-Spam-Status: No, score=-1.595 tagged_above=-999 required=5 tests=[AWL=-0.219, 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 nWMyF0tQmepj for <mmox@core3.amsl.com>; Wed, 18 Mar 2009 07:10:47 -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 86B703A687C for <mmox@ietf.org>; Wed, 18 Mar 2009 07:10:46 -0700 (PDT)
Received: by ewy9 with SMTP id 9so54767ewy.37 for <mmox@ietf.org>; Wed, 18 Mar 2009 07:11:30 -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=0lmJbuh4tfZD73s4AD30U/F4s8g4xsf688Q+nj9TNeQ=; b=DxyD08JmF7LWjZewqCpVfsIXQO4fBxG8tKILZVpVnmsTa+mXpv0wSa7Rg1ueseXr84 +XByuWWrIMda79EXjTWCyug8Q4a7ug7/XfM6G+7Olwo6pQ3AHPH1YDfcbYMyYXR42oD4 7RvI7Yxg1FGCrPQqsvB63tFQLCzVLKiXA+1Hg=
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=JoimjuQmeCN4lMJniT1xpL9Z/pDumovZKo5y4Lq+ss6p+qRd3twVkH6uT3ngl5Tj1C aNcYnPJLSPtstbD6FP8G0lw0Bq6cxO71oDtfhzxhWyG7YpkP22wMOErVVSOpEJPZc4vh sN4qo764BDfrmLskMkgOkzqhbiuBMwl6PXRE8=
MIME-Version: 1.0
Received: by 10.210.22.16 with SMTP id 16mr991150ebv.24.1237385490055; Wed, 18 Mar 2009 07:11:30 -0700 (PDT)
In-Reply-To: <3B6FBE24-68BA-4E23-908F-E7ED0BB5B73B@lindenlab.com>
References: <e0b04bba0903120735s5311a922ybbc40a30433166a3@mail.gmail.com> <3B6FBE24-68BA-4E23-908F-E7ED0BB5B73B@lindenlab.com>
Date: Wed, 18 Mar 2009 14:11:30 +0000
Message-ID: <e0b04bba0903180711u625a383dqe91bee4cc7918e69@mail.gmail.com>
From: Morgaine <morgaine.dinova@googlemail.com>
To: Mark Lentczner <markl@lindenlab.com>
Content-Type: multipart/alternative; boundary="0015174be0d095c6a90465654282"
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 14:10:48 -0000

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
>