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

[Han Sontse <[e-mail]>]

Your point is well taken.  I do think that even within the SL-like
space their is considerable room for innovation.

I offered up the WoW and EVE Online as examples where
the mapping of V-space is considerably different.

It may be that one way to manage this is to have a mapping service
tell the client about locations in the local V-space that will require
more information from the mapping service.  The semantics here
are along the lines of, if you intend to enter one of the v-space
volumes in the list, please request more information from the mapping
service.

Example:
Client enters a region, and gets the local coordinate space.
Within that v-space, the mapping system gives the client a list
of "points of note" in that mapping where the client would request
more information about the mapping.  This type of mapping
would not be providing details on parcels, but only those types of  
mappings that
might result in an instance, a shard, or some other change in the  
simulation
that could result in a change of the endpoints the client is  
communicating with.

Open a door, and walk through.... now you are on a different simulator  
that is
handling isolated conference room simulations, or a private  
residential space,
that may have a very different relationship to the global region map,  
if it has any at all.

Han

On Jan 21, 2010, at 11:32 AM, Meadhbh Hamrick wrote:

> hmm... we should be careful thought, han.
>
> the scope of VWRAP was intentionally limited to "Second Lifelike"
> worlds. the MMOX BoF demonstrated there was broad interest in MMOs,
> but that the technology and approaches and interaction models were so
> diverse, it would have been EXTREMELY difficult to get us to all agree
> to a spec that would support all our use cases.
>
> so yeah. let's take what lessons we can from WoW and Eve Online, but
> let's not think we have to support them as use cases.
>
> i don't think we have to support arbitrary geometry. i mean, sure, it
> would be great, but the problem domain we're working on is "second
> lifelike" worlds. you have a 3d space partitioned into regions. but i
> think we may be expanding the scope of the world to include the
> concept of a shard or using a tensor to describe the shape of space in
> a region.
>
> On Thu, Jan 21, 2010 at 11:05 AM, Han Sontse  
> <[e-mail]> wrote:
>> 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
>>> <[e-mail]> 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 <[e-mail] 
>>>> >
>>>> 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
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/ogpx
>>>>>
>>>>>
>>>> _______________________________________________
>>>> ogpx mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/ogpx
>>>>
>>> _______________________________________________
>>> ogpx mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ogpx
>>
>> _______________________________________________
>> ogpx mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ogpx
>>