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

[Meadhbh Hamrick <[e-mail]>]

hmm. i kinda like this idea.

we may want to choose a rectangular coordinate system as the default.

so yeah, maybe the mapping service is "the thing" that defines what
we're now alternately calling a virtual world, grid or instance. so we
could have a simple service like this that describes the grid:

%% grid/info
<< {
  grid_name : string,
  coordinates : string,
  map_service : uri
}

and you could plug in values of "spherical" or "cylindrical" in the
coordinates entry, but have "rectangular" be the default. the
"map_service" URI could be the URI used to convert a region name +
point in space into a URI for requesting services like teleport, map
tiles, spatial chat, etc.

so... for example... i could have a grid/info entry for SL's vaak test
grid at http://util.vaak.lindenlab.com/. when you did a HTTP GET on
it, you would get the blob:

<?xml version="1.0"?>
<llsd>
  <map>
    <key>grid_name</key>
    <string>vaak</string>
    <key>map_service</key>
    <uri>http//util.vaak.lindenlab.com/services/map</uri>
  </map>
</llsd>

the map service at http//util.vaak.lindenlab.com/services/map could be
queried to get information and/or caps to access locations. so you
could construct a service like:

%% location/info
<< {
  teleport_cap : uri,
  map_tile : uri,
  spatial_chat_cap : uri
}

so when you did a get on
http//util.vaak.lindenlab.com/services/map?location_x=128&location_y=128&location_z=32&region_name=Ahern
you might get a response like:

<?xml version="1.0"?>
<llsd>
  <map>
    <key>teleport_cap</key>
    <uri>http://sim1.vaak.lindenlab.com/c/0953E063-5B31-4B62-B218-A7C0CE1FC391</uri>
    <key>map_tile</key>
    <uri>http://s3.amazonaws.com/foo/bar/ahern.jpg</uri>
    <key>spatial_chat_cap</key>
    <uri>http://sim1.vaak.lindenlab.com/c/4AFA1BAF-4FAD-45A5-A683-6244BC81A660</uri>
  </map>
</llsd>

and the teleport_cap would be the one that gets used if someone wanted
to teleport to the location.

hope this makes sense.

-cheers
-meadhbh
On Thu, Jan 21, 2010 at 12:12 PM, Han Sontse <[e-mail]> wrote:
> 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
>>>
>
>