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.
- Re: [mmox] OGP scalability concerns Meadhbh Hamrick (Infinity)
- [mmox] OGP scalability concerns Hurliman, John
- Re: [mmox] OGP scalability concerns Morgaine
- Re: [mmox] OGP scalability concerns Meadhbh Hamrick (Infinity)
- Re: [mmox] OGP scalability concerns Charles Krinke
- Re: [mmox] OGP scalability concerns Meadhbh Hamrick (Infinity)
- Re: [mmox] OGP scalability concerns Jon Watte
- Re: [mmox] OGP scalability concerns Charles Krinke
- Re: [mmox] OGP scalability concerns Lawson English
- Re: [mmox] OGP scalability concerns Meadhbh Hamrick (Infinity)
- Re: [mmox] OGP scalability concerns Jon Watte
- Re: [mmox] OGP scalability concerns Meadhbh Hamrick (Infinity)
- Re: [mmox] OGP scalability concerns Charles Krinke
- Re: [mmox] OGP scalability concerns Morgaine
- Re: [mmox] OGP scalability concerns Jason Giglio
- Re: [mmox] OGP scalability concerns Rob Lanphier
- Re: [mmox] OGP scalability concerns Morgaine
- Re: [mmox] OGP scalability concerns Jon Watte
- Re: [mmox] OGP scalability concerns Jon Watte
- Re: [mmox] OGP scalability concerns Christian Scholz
- Re: [mmox] OGP scalability concerns Hurliman, John
- Re: [mmox] OGP scalability concerns Christian Scholz
- Re: [mmox] OGP scalability concerns Jon Watte
- Re: [mmox] OGP scalability concerns Christian Scholz
- Re: [mmox] OGP scalability concerns Meadhbh Hamrick (Infinity)
- Re: [mmox] OGP scalability concerns Meadhbh Hamrick (Infinity)
- Re: [mmox] OGP scalability concerns Meadhbh Hamrick (Infinity)
- Re: [mmox] OGP scalability concerns Jon Watte
- Re: [mmox] OGP scalability concerns Meadhbh Hamrick (Infinity)
- Re: [mmox] OGP scalability concerns Charles Krinke
- Re: [mmox] OGP scalability concerns Hurliman, John
- Re: [mmox] OGP scalability concerns Meadhbh Hamrick (Infinity)
- Re: [mmox] OGP scalability concerns Meadhbh Hamrick (Infinity)
- Re: [mmox] OGP scalability concerns Charles Krinke
- Re: [mmox] OGP scalability concerns Jon Watte
- Re: [mmox] OGP scalability concerns Christian Scholz
- Re: [mmox] OGP scalability concerns Christian Scholz
- Re: [mmox] OGP scalability concerns Christian Scholz
- Re: [mmox] OGP scalability concerns Morgaine
- Re: [mmox] OGP scalability concerns Charles Krinke
- Re: [mmox] OGP scalability concerns Christian Scholz
- Re: [mmox] OGP scalability concerns Jon Watte
- Re: [mmox] OGP scalability concerns Hurliman, John
- Re: [mmox] OGP scalability concerns Christian Scholz