Re: [mmox] OGP scalability concerns

Christian Scholz <> Mon, 06 April 2009 21:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4B8563A6866 for <>; Mon, 6 Apr 2009 14:55:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.114
X-Spam-Status: No, score=-2.114 tagged_above=-999 required=5 tests=[AWL=-0.115, BAYES_00=-2.599, J_CHICKENPOX_36=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6vPt-xPFOm2e for <>; Mon, 6 Apr 2009 14:55:39 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8E2643A6885 for <>; Mon, 6 Apr 2009 14:55:36 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id EBBBE1CE016F; Mon, 6 Apr 2009 23:56:41 +0200 (CEST)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oq9CsbNi6MaD; Mon, 6 Apr 2009 23:56:40 +0200 (CEST)
Received: from [] ( []) by (Postfix) with ESMTP id EB5D21CE00EA; Mon, 6 Apr 2009 23:56:39 +0200 (CEST)
Message-ID: <>
Date: Mon, 06 Apr 2009 23:56:37 +0200
From: Christian Scholz <>
User-Agent: Thunderbird (Windows/20090302)
MIME-Version: 1.0
To: Jon Watte <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: "" <>
Subject: Re: [mmox] OGP scalability concerns
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Massively Multi-participant Online Games and Applications <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 06 Apr 2009 21:55:47 -0000

Jon Watte schrieb:
> Christian Scholz wrote:
>> So lets look at the spec as it is right now:
>> And maybe we should use the same terminology because I might simply be
>> confused ;-)
> That is a re-wording and clarification of the version I had previously 
> read.


> I guess the question then is whether service provider implementations 
> require the callback URL in their implementation, or whether they'll be 
> OK with a NULL callback URL. I know of at least one service provider 
> that has a form submission to obtain an application key where the 
> callback URL cannot be left empty, but maybe it can be redirected to 
> some URI that does nothing.

Remember that OAuth is still fairly new and not all use cases or best 
practices have been researched fully yet. But now with Twitter also 
moving towards OAuth more people discover some potential problems such 
as that callback URL, e.g. iPhone applications.
There is some workaround though which was discussed regarding those apps 
which is using a protocol handler, e.g. secondlife:oauth_success which 
could then be catched by that respective application in case of desktop 
or iPhone apps.
You can of course also simply redirect to a dummy URI which simply 
instructs the user to click "Continue" on the original web page.

> Regarding service discovery: Does anyone want to start talking about XRDS?

Of course, although it's probably replaced soon by the XRD spec (sneak 
peak and examples here:

So I guess we should name our little project simply "Service Discovery" 
and we need to find out what we actually want to do. The XRD spec for 
describing resources and the LRRD spec for discovering where to find the 
XRD document are already being written so our task might be to check if 
and how they are applicable to our problem space.

So we might need some use cases and requirements and the output might 
eventually be some description of how to apply the XRD suite to our problem.

I personally would be very much interested in what bigger parts a 
virtual world might actually consist of. Right now I guess it's a client 
and a server (or a cluster) in most cases, except Croquet which is only 
clients (is that right?). Now if we decompose things the question is how 
the actual workflow from starting the client to appearing in some 
simulator for other users might look like. And how moving from one 
simulator to another (usually called teleport, technically a login or 
handshake) might look like.

-- Christian

COM.lounge GmbH
Hanbrucher Strasse 33, 52064 Aachen
Amtsgericht Aachen HRB 15170
Geschäftsführer: Dr. Ben Scheffler, Christian Scholz

fon: +49-241-4007300
fax: +49-241-97900850

personal email:
personal blog:
personal podcasts:,