Re: [mmox] OGP scalability concerns
Christian Scholz <cs@comlounge.net> Fri, 03 April 2009 09:23 UTC
Return-Path: <cs@comlounge.net>
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 18CC228C13F for <mmox@core3.amsl.com>; Fri, 3 Apr 2009 02:23:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.129
X-Spam-Level:
X-Spam-Status: No, score=-2.129 tagged_above=-999 required=5 tests=[AWL=-0.130, BAYES_00=-2.599, J_CHICKENPOX_36=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 aRtpIktNL2t7 for <mmox@core3.amsl.com>; Fri, 3 Apr 2009 02:23:15 -0700 (PDT)
Received: from post.comlounge.net (post.comlounge.net [85.214.59.142]) by core3.amsl.com (Postfix) with ESMTP id A7C5B28C134 for <mmox@ietf.org>; Fri, 3 Apr 2009 02:23:00 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by post.comlounge.net (Postfix) with ESMTP id BE7881CE024D; Fri, 3 Apr 2009 11:24:02 +0200 (CEST)
Received: from post.comlounge.net ([127.0.0.1]) by localhost (h1346004.stratoserver.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yGHNA83dZC1c; Fri, 3 Apr 2009 11:24:01 +0200 (CEST)
Received: from [192.168.2.101] (pC19EAD7C.dip.t-dialin.net [193.158.173.124]) by post.comlounge.net (Postfix) with ESMTP id 759161CE0039; Fri, 3 Apr 2009 11:24:01 +0200 (CEST)
Message-ID: <49D5D5B2.7030408@comlounge.net>
Date: Fri, 03 Apr 2009 11:24:02 +0200
From: Christian Scholz <cs@comlounge.net>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: "Hurliman, John" <john.hurliman@intel.com>
References: <62BFE5680C037E4DA0B0A08946C0933D7B692E1B@rrsmsx506.amr.corp.intel.com> <CD02023C-3E7B-4E76-8429-11035C827E53@lindenlab.com> <f0b9e3410904011701i2ccb03d4r1b48d33cfe3988ea@mail.gmail.com> <49D40A06.7030708@gmail.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>
In-Reply-To: <62BFE5680C037E4DA0B0A08946C0933D7B693676@rrsmsx506.amr.corp.intel.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
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 09:23:16 -0000
Hurliman, John schrieb: >> we also use the term "domain" in it's more traditional sense to >> imply a bounds of authority. which is to say, we assume that all >> hosts and services inside a domain are administered by the same >> entity. that being said, there's no reason you can't have >> sub-domains, and there's no reason that two services associated >> with "the" agent domain can't be split across two administrative >> domains (like maybe yahoo or AOL get in the business of moving >> virtual world IM messages but don't want to deploy a world >> themselves.) it would require some coordination of identity >> management issues, but i'm sure they're tractable. > > 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 > Using the current evolution of the web as historical evidence and > assuming that specialized service providers will be the norm, lumping > together instant messaging and content hosting under the same > umbrella doesn't make any sense. This is why I'm in favor of starting > from the ground up and defining each use case and service endpoint, > rather than trying to figure out clever ways of shoehorning the > "right" approach into Linden Lab's OGP. +1 -- Christian -- COM.lounge GmbH http://comlounge.net Hanbrucher Strasse 33, 52064 Aachen Amtsgericht Aachen HRB 15170 Geschäftsführer: Dr. Ben Scheffler, Christian Scholz email: info@comlounge.net fon: +49-241-4007300 fax: +49-241-97900850 personal email: cs@comlounge.net personal blog: http://mrtopf.de/blog personal podcasts: http://openweb-podcast.de, http://datawithoutborders.net
- 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