Re: [ogpx] URI schema for virtual world locations?

Han Sontse <han.sontse.sl@gmail.com> Thu, 21 January 2010 19:06 UTC

Return-Path: <han.sontse.sl@gmail.com>
X-Original-To: ogpx@core3.amsl.com
Delivered-To: ogpx@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E244E3A6A8F for <ogpx@core3.amsl.com>; Thu, 21 Jan 2010 11:06:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 Q5B5kcTfs821 for <ogpx@core3.amsl.com>; Thu, 21 Jan 2010 11:06:03 -0800 (PST)
Received: from mail-pz0-f198.google.com (mail-pz0-f198.google.com [209.85.222.198]) by core3.amsl.com (Postfix) with ESMTP id 94A8E3A6A77 for <ogpx@ietf.org>; Thu, 21 Jan 2010 11:06:03 -0800 (PST)
Received: by pzk36 with SMTP id 36so232380pzk.5 for <ogpx@ietf.org>; Thu, 21 Jan 2010 11:05:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=5ufNrbgJkXugBdnwvTgsD9djLZ2OxQ9f5cQEhxUCyJI=; b=LKcS+b6uOlNA06Uyq3RtN9P8rLl64sqVgeUpWExeEr+J9L0ynscfFqPeWDLqYyzhfu DHdnOpI2vRAwweCJ7vLwOKQ8fliYKSYZwO1jgnieY//c34oA/4Em0jhBGzRTNmuZEzKH +3SFHFE9Sgdr+Xfabi30jsUR13yycTXbIH0ho=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=rCvjyrrcL0KJkljxIy1SvS3tWPZjoXTb2aJ5mETENv6Ico+XQSBweGPSArLPDaEgJi AY22NvikjAEwnM0RektZW6MqdzXTlpCjJABfQ00ei9Iu5aHoMqzvYANkIEPbQc1oc7hf ykrnzLOZV78TjFRonouWOfjyVMrFdhLxCw2Ew=
Received: by 10.114.163.3 with SMTP id l3mr1244374wae.151.1264100756143; Thu, 21 Jan 2010 11:05:56 -0800 (PST)
Received: from ?192.168.1.57? ([98.125.170.50]) by mx.google.com with ESMTPS id 20sm163129pzk.9.2010.01.21.11.05.55 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 21 Jan 2010 11:05:55 -0800 (PST)
Message-Id: <8FB8EE72-4938-4DA2-8134-6496DBF6ADE5@gmail.com>
From: Han Sontse <han.sontse.sl@gmail.com>
To: ogpx@ietf.org
In-Reply-To: <a768bcd91001211023h7e502394y9a65b399f1ee4b56@mail.gmail.com>
Content-Type: text/plain; charset="WINDOWS-1252"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v936)
Date: Thu, 21 Jan 2010 11:05:49 -0800
References: <62BFE5680C037E4DA0B0A08946C0933DC4B2DC80@rrsmsx506.amr.corp.intel.com> <b8ef0a221001211005l65f771edwa7eb1f228d9ee6fa@mail.gmail.com> <a768bcd91001211023h7e502394y9a65b399f1ee4b56@mail.gmail.com>
X-Mailer: Apple Mail (2.936)
Subject: Re: [ogpx] URI schema for virtual world locations?
X-BeenThere: ogpx@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Virtual Worlds and the Open Grid Protocol <ogpx.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ogpx>, <mailto:ogpx-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ogpx>
List-Post: <mailto:ogpx@ietf.org>
List-Help: <mailto:ogpx-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ogpx>, <mailto:ogpx-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Jan 2010 19:06:05 -0000

Kari included a number of dimensional axes in the example that began  
this discussion thread.

  It is easy to assume a SL compatible schema, but other examples of  
VWs in current use,
such as WoW and EVE express unique locations in very different schema.  
Through a typical
  user cannot see all of the axes in use to describe the unique  
position, the
client clearly needs to be aware of the mapping.

I'd like to suggest that we find a VWRAP appropriate way for a client  
to discover what the
positional axes of a VW are, and how they should be interpreted.

While I don't know exactly how WoW manages location specification I do  
know that
when you enter a building, or a cave (not an instance) that the local  
coordinate system
gets remapped.  I also know that inside of an instance the local  
coordinate system has
no relationship to the coordinate system the client was in  
previously.  This has peculiar
consequences for some 3rd party UI extensions since they lose their  
ability to create
useful overlays with an instance, but do not have problems within a  
building.
Also within a WoW named continent,  regions such as Felwood, (kind of  
like a county) the mapping is different
than the neighboring region.  It's not clear at all how all of this  
maps to their server nodes either.

In EVE, I recently read that they can arbitrarily instance a region of  
space in a large server cluster to facilitate huge
battles between factions.   Their regular servers cannot manage the  
loads these potentially massive battles generate.
They must do this manually with a request from the two factions  
involved to set this up.   I imagine eventually they might
be able to detect a war starting auto-magically and instance the  
region of conflict accordingly.  But these issues imply that
we cannot count on a static mapping of any particular location schema.

It is very important to develop a mechanism that allows service  
providers to  describe their various location schema, and their  
relationships, in a manner that creates as few restrictions as  
possible.  We cannot know what VW architecture will look like in the  
future, or how a particular world is going to specify unique locations  
within their domains, or even if those mappings will remain static  
during the session.


Han

On Jan 21, 2010, at 10:23 AM, Dan Olivares wrote:

> Counter Proposal:
>
> If we're going to not use URIs..    which were meant as resource
> locators....   and make our own resource locators..   lets at least
> include all of the relevant information to make our own technology
> effective.
>
> ---- Modifications to previous proposal-----
> so rather than have something like:
>
>  secondlife://example.com/Levenhall/128/128/32
>
> we would define a LLIDL map like:
>
> {
>
> region_protocol: string,
> region_address : string,
> region_port: int,
> region_name : string,
> location : [ int, int, int ]
> }
>
> and then serialize it as:
>
> <?xml version="1.0" encoding="utf-8"?>
> <llsd>
> <map>
>   <key>region_protocol</key>
>   <string>OGP</string>
>   <key>region_address</key>
>   <string>myregion.mycoolsimulatorfarm.com</string>
>   <key>region_port</key>
>   <int>94</int>
>   <key>region_name</key>
>   <string>Levenhall</string>
>   <key>location</key>
>   <array>
>     <integer>128</integer>
>     <integer>128</integer>
>     <integer>32</integer>
>   </array>
> <map>
> </llsd>
>
> Possible protocols could be XMLRPC, OGP/VWrap, <insert another 3rd
> party system here>.
> Instead of the region_address, region_port, and region_protocol, it
> could potentially have the http address to the region domain.
>
> LLIDL map like:
>
> {
>
> region_domain: string,
> region_name : string,
> location : [ int, int, int ]
> }
>
> and then serialize it as:
>
> <?xml version="1.0" encoding="utf-8"?>
> <llsd>
> <map>
>   <key>region_domain</key>
>   <string>http://www.osgrid.org/VWrap/RegionDomain/put</string>
>   <key>region_name</key>
>   <string>Levenhall</string>
>   <key>location</key>
>   <array>
>     <integer>128</integer>
>     <integer>128</integer>
>     <integer>32</integer>
>   </array>
> <map>
> </llsd>
> ...
>
> Daniel Olivares
> http://www.google.com/profiles/dcolivares
>
>
> On Thu, Jan 21, 2010 at 1:05 PM, Meadhbh Hamrick
> <meadhbh.siobhan@gmail.com> wrote:
>> the seondlife URI scheme is a hack used to automagically launch the  
>> SL
>> viewer based on web interaction like with the map @ slurl.com. as i
>> read it, the point of a location URI in the protocol is to provide a
>> mechanism for carrying information in a point in a virtual world.
>> instead of abusing URIs like we have in the past, maybe we should
>> define a LLIDL map for containing information about a location, then
>> use more traditional URLs to point to the location of these services.
>>
>> so rather than have something like:
>>
>>   secondlife://example.com/Levenhall/128/128/32
>>
>> we would define a LLIDL map like:
>>
>> {
>>  region_name : string,
>>  location : [ int, int, int ]
>> }
>>
>> and then serialize it as:
>>
>> <?xml version="1.0" encoding="utf-8"?>
>> <llsd>
>>  <map>
>>    <key>region_name</key>
>>    <string>Levenhall</string>
>>    <key>location</key>
>>    <array>
>>      <integer>128</integer>
>>      <integer>128</integer>
>>      <integer>32</integer>
>>    </array>
>>  <map>
>> </llsd>
>>
>> and maybe make them available at a traditional URL like:
>>
>> http://example.com/regions/3F05D047-B5AF-4332-938E-675A1EA1D784
>>
>> this would have the advantage that implementers could easily stuff
>> experimental new parameters into the serialization. if we used the
>> mime types in the client application launch message draft (
>> http://tools.ietf.org/html/draft-hamrick-ogp-launch-00 ) then we  
>> could
>> hack our web browsers to recognize the application/ogpcal+xml content
>> type and pass it to a client application of our choice.
>>
>> so.. to recap.. secondlife style URIs should be deprecated (or at
>> least not used in VWRAP.) we should use URLs that use a well known
>> protocol (like https) that describe a protocol endpoint for  
>> retrieving
>> an LLSD blob with the information we're interested in.
>>
>> -cheers
>> -meadhbh
>>
>> On Wed, Jan 20, 2010 at 1:24 PM, Hurliman, John <john.hurliman@intel.com 
>> > wrote:
>>> I’ve seen a few places in the I-Ds and OGP wiki documents that  
>>> refer to a
>>> URI schema for a location in a virtual world (home location,  
>>> requested login
>>> location, etc). Has this been defined or discussed yet? I see the  
>>> SLURL
>>> format of:
>>>
>>>
>>>
>>> secondlife://region%20name/x/y/z
>>>
>>>
>>>
>>> How would this change to accommodate a location in any region  
>>> domain?
>>>
>>>
>>>
>>> John
>>>
>>> _______________________________________________
>>> ogpx mailing list
>>> ogpx@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ogpx
>>>
>>>
>> _______________________________________________
>> ogpx mailing list
>> ogpx@ietf.org
>> https://www.ietf.org/mailman/listinfo/ogpx
>>
> _______________________________________________
> ogpx mailing list
> ogpx@ietf.org
> https://www.ietf.org/mailman/listinfo/ogpx