Re: [mmox] User Accounts / "Object" Transfer.

Morgaine <morgaine.dinova@googlemail.com> Thu, 19 February 2009 18:09 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 EEA723A68C8 for <mmox@core3.amsl.com>; Thu, 19 Feb 2009 10:09:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.873
X-Spam-Level:
X-Spam-Status: No, score=-1.873 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
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 W3IvM08IoTyY for <mmox@core3.amsl.com>; Thu, 19 Feb 2009 10:09:29 -0800 (PST)
Received: from mail-bw0-f161.google.com (mail-bw0-f161.google.com [209.85.218.161]) by core3.amsl.com (Postfix) with ESMTP id 21F9D3A6A25 for <mmox@ietf.org>; Thu, 19 Feb 2009 10:09:28 -0800 (PST)
Received: by bwz5 with SMTP id 5so1505172bwz.13 for <mmox@ietf.org>; Thu, 19 Feb 2009 10:09:41 -0800 (PST)
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=Ziy6x10bwqHG4kE3KeUaPHa1oq0RMH4t0IuakKzZX2k=; b=gAJHT1SKRKcZXLdVos0FyIpUAzL3UpNdChP4eyV6fvXMre9eTmUbo1lfZ0FagCOTGD BUaK48QH6vYrpN11xVHMFIdPQn3LCt5hmX8pux7zM3NkQlhDmUVY5IyNqj9lXB2rYrj/ NyiIc/bSYomPk1LNOVD5TJ6tcTBXsY6BpGcpE=
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=BOQF2WSbIOLGW7mGVsyNI24oCtHU/Fs5CxyCDc3ETwcMSLcmOX1Ci7cx9KwlJU+NAD Xi5iAv91UqGTzAFXduB1zGXvGkVcf3R2d7zT5CQ8wmy9+GjPJgO0GErp+wcCekYHjPnm RjuCIKentgqj4gAmBvZTysXFaGv77eAKQs9fk=
MIME-Version: 1.0
Received: by 10.181.199.16 with SMTP id b16mr3289420bkq.142.1235066981429; Thu, 19 Feb 2009 10:09:41 -0800 (PST)
In-Reply-To: <e0b04bba0902182339k2feed500yffc10219041417bc@mail.gmail.com>
References: <mailman.11.1234814402.16516.mmox@ietf.org> <27a487810902170721m31a157b1oed853cdd9cc6e500@mail.gmail.com> <548919.2383.qm@web82607.mail.mud.yahoo.com> <1234917818.6664.51.camel@localhost> <77186.32658.qm@web59104.mail.re1.yahoo.com> <499C7FAD.4080009@gmail.com> <e0b04bba0902182339k2feed500yffc10219041417bc@mail.gmail.com>
Date: Thu, 19 Feb 2009 18:09:41 +0000
Message-ID: <e0b04bba0902191009h77cebc1eof2abb8faed7fb15e@mail.gmail.com>
From: Morgaine <morgaine.dinova@googlemail.com>
To: Jon Watte <jwatte@gmail.com>
Content-Type: multipart/alternative; boundary="0016e6d59d1db3b41604634970a5"
Cc: mmox@ietf.org
Subject: Re: [mmox] User Accounts / "Object" Transfer.
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, 19 Feb 2009 18:09:31 -0000

Jon, after reading your other posts, I think that you may have been
referring to your "shared-spaces" idea when you questioned the value of
"teleport between grids", as I can't see any other architecture being
discussed.

However, if that's the case then I don't understand the point being made,
because shared-spaces seems to be a "teleport only" architecture.  The only
means by which a user can go from one shared space to another is by
teleport, since shared spaces do not have topological relationships to each
other, from your description.

If you ignore the local simulation for a moment, then what happens when one
of your users changes from one local shared space to one belonging to a
different provider is very similar in implementation to the usual separate
worlds case:  the agent appears in the space at the remote end.   Adding a
local simulation on top of that doesn't really change the matter.  That's
teleport between grids, plus a local accelerator.

And perceptually from the users' perspective, the model suggests that they
too see a teleport occurring every time that they change their shared space
to one operated by a different world provider.  This looks like perfectly
ordinary "teleport between grids" to them too.

Morgaine.




On Thu, Feb 19, 2009 at 7:39 AM, Morgaine <morgaine.dinova@googlemail.com>wrote:

>
>
> On Wed, Feb 18, 2009 at 9:37 PM, Jon Watte <jwatte@gmail.com> wrote:
>
>> What end-user value does "teleport between grids" solve?
>>
>> In my opinion, that feature is very un-interesting, as it requires lots of
>> engineering, and gives very little value, compared to lower-hanging fruit
>> like physical spaces shared across interoperating servers.
>>
>> After perception of the world around you, travel is the next most
> important form of interaction with the world.  Teleport is simply
> instantaneous travel, and teleport between grids is simply instantaneous
> travel between worlds in different organizational domains.  How can it
> possibly be uninteresting and give little value to travel to distant places
> in virtual space?  ;-)
>
> I expect that you meant something *completely* different to the above.
> :-)   Are we hitting an ambiguity in terminology of some kind here?
>
> Morgaine.
>