Re: [mmox] OGP scalability concerns

Morgaine <morgaine.dinova@googlemail.com> Fri, 03 April 2009 10:57 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 8ADF53A6B65 for <mmox@core3.amsl.com>; Fri, 3 Apr 2009 03:57:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.886
X-Spam-Level:
X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[AWL=0.090, 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 xl-drmiQHS0I for <mmox@core3.amsl.com>; Fri, 3 Apr 2009 03:57:23 -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 33A853A68C7 for <mmox@ietf.org>; Fri, 3 Apr 2009 03:57:22 -0700 (PDT)
Received: by ewy9 with SMTP id 9so930361ewy.37 for <mmox@ietf.org>; Fri, 03 Apr 2009 03:58:24 -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=K+mBn5S+QeQ1F081KZ1qm9f5YZElbFilbjzCMXTbm5M=; b=aru6IoGYJqgL7DdTuZdADoeyFBk/o1fceG3FdSL882gYzGQnC2/QgdqVyTqyzrJ6oQ MznETvCG6Z7s5Mdo5bMel9iO0fVKeQYkVS+lTs3LnIA+R9i2O6x67dJOXkjBdbzuulps HJg37Q5QhrUmreQBOMds5g0LSNHuzjrhge03w=
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=LLhn/LZqzhZjaQ4c6UT1f7KmAnIOyWGbB3HZdD/ppI7ujCYHD8IvvI3DRdv2GafkqP zFoABSBYZHWVL/tag7nlZr4xEGI2dtOoJTxRR4aL9Q5Dh2fkTBl5hUIA/gwVQjyDqe4+ Y/1KECNQ/lsKVpS9voIQS0HmUbFIp5D89W8Ag=
MIME-Version: 1.0
Received: by 10.216.26.80 with SMTP id b58mr368345wea.35.1238756304563; Fri, 03 Apr 2009 03:58:24 -0700 (PDT)
In-Reply-To: <49D5D5B2.7030408@comlounge.net>
References: <62BFE5680C037E4DA0B0A08946C0933D7B692E1B@rrsmsx506.amr.corp.intel.com> <8D793BD8-6AA2-49C7-96EF-435A5B449AA6@lindenlab.com> <49D4295C.2020502@gmail.com> <52A129B8-3FC6-486A-99A5-C00BED8BDE08@lindenlab.com> <49D4E5AF.2030301@gmail.com> <49D51A7D.8000104@comlounge.net> <62BFE5680C037E4DA0B0A08946C0933D7B6934A3@rrsmsx506.amr.corp.intel.com> <D61EE1DB-11DF-4471-A000-9104CD11B219@lindenlab.com> <62BFE5680C037E4DA0B0A08946C0933D7B693676@rrsmsx506.amr.corp.intel.com> <49D5D5B2.7030408@comlounge.net>
Date: Fri, 03 Apr 2009 11:58:24 +0100
Message-ID: <e0b04bba0904030358y722dfeaat8f17c2a6ae509a7a@mail.gmail.com>
From: Morgaine <morgaine.dinova@googlemail.com>
To: Christian Scholz <cs@comlounge.net>
Content-Type: multipart/alternative; boundary="001485f423dc7f2f640466a46dd2"
Cc: "mmox@ietf.org" <mmox@ietf.org>
Subject: Re: [mmox] OGP scalability concerns
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: Fri, 03 Apr 2009 10:57:24 -0000

John and Christian together have nailed a great candidate for the first step
in the process of interoperation, I believe.  Such initial unauthenticated
service discovery would provide the opportunity for choice that leads to
decoupling of services, whereas asking a bundling-prone VW provider for
options is predestined to offer you very little real choice.

On Fri, Apr 3, 2009 at 10:24 AM, Christian Scholz <cs@comlounge.net> wrote:

Hurliman, John schrieb:
>
>> I understand this. If you are Linden Lab and you are already in the
>> business of running lots of independent services (content hosting,
>> identity storage and authorization, instant messaging, inventory
>> servers, simulators, etc) then it makes sense to lump every service
>> you want to provide under one trust domain. Simulation can be a
>> different domain so third party simulators like OpenSim can run under a
>> separate trust domain and optionally connect to the aggregate Linden Lab
>> service cloud. Tada! You have OGP. It's a great business model.  Unless you
>> are any company *except* Linden Lab and you want to provide a service such
>> as content hosting without becoming a full virtual world service provider.
>>
>
> It also reminds me of Facebook and Facebook connect where you also only get
> all or nothing. Moreover FB also defines who actually has access to _your_
> data (e.g. Google has not). Nevertheless other players such as MySpace or
> Yahoo (and others) are becoming more open in a per-service level, e.g.
> providing OAuth based access to profile or friends data.
>
> What's missing there is still some way to list all of your services
> together and to find out which services a site provides. But there is work
> going on to solve these problems. I guess a good resource is Eran's blog
> (which I also should monitor more closely as a lot has happened there since
> I last looked, namely thoughts about delegated authorization as we might
> need it and XRD vs. XRDS):
>
>
> <http://www.hueniverse.com>

Those really are excellent points.


Morgaine.