Re: [mmox] OGP scalability concerns

"Meadhbh Hamrick (Infinity)" <infinity@lindenlab.com> Fri, 03 April 2009 00:16 UTC

Return-Path: <infinity@lindenlab.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 9A2A13A684C for <mmox@core3.amsl.com>; Thu, 2 Apr 2009 17:16:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.511
X-Spam-Level:
X-Spam-Status: No, score=-3.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 8wm-Q9TRz7yF for <mmox@core3.amsl.com>; Thu, 2 Apr 2009 17:16:53 -0700 (PDT)
Received: from tammy.lindenlab.com (tammy.lindenlab.com [64.154.223.128]) by core3.amsl.com (Postfix) with ESMTP id 95F5A3A6BB9 for <mmox@ietf.org>; Thu, 2 Apr 2009 17:16:52 -0700 (PDT)
Received: from regression.lindenlab.com (regression.lindenlab.com [10.1.16.8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tammy.lindenlab.com (Postfix) with ESMTP id CCD571414003; Thu, 2 Apr 2009 17:17:54 -0700 (PDT)
Message-Id: <606A71E4-A150-4832-AFE7-C7947E728DCE@lindenlab.com>
From: "Meadhbh Hamrick (Infinity)" <infinity@lindenlab.com>
To: "Hurliman, John" <john.hurliman@intel.com>
In-Reply-To: <62BFE5680C037E4DA0B0A08946C0933D7B693676@rrsmsx506.amr.corp.intel.com>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Thu, 02 Apr 2009 17:17:54 -0700
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>
X-Mailer: Apple Mail (2.930.3)
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 00:16:54 -0000

i would argue that there _are_ in fact OpenSim operators who would  
want to connect to linden servers and consume linden services.

we use URIs as caps and mandate consumers of these caps treat them as  
opaque web addresses explicitly because we want to support the use  
case where the host that responds to a seed cap request can provide a  
URI in a different administrative domain for other services.. um..  
like.. i dunno.. like where your identity and presence is managed on a  
server distinct from the one that provides SIP/RTP voice services.

i applaud your effort to shoehorn technologies into a codebase. we'll  
be over here trying to build a coherent set of services whose use  
semantics are conformable.

-cheers
-meadhbh

On Apr 2, 2009, at 5:02 PM, Hurliman, John wrote:

>> 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.
>
> 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.
>
> John
> _______________________________________________
> mmox mailing list
> mmox@ietf.org
> https://www.ietf.org/mailman/listinfo/mmox