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

[Meadhbh Hamrick <[e-mail]>]

we may be having some terminology fail here.

in a client / server architecture, the server is the host (or process)
that exposes an interface and provides a service to processes on hosts
that request it. so in this sense, i think we can assume a client is
the requester of a service on a server. in this model, the word
"client" means "the process or host that's requesting the service." it
doesn't mean a viewer or browser. (though viewers or browsers are
clients, as are server processes that are requesting a service from
another process.)

in theory, it would be nice to use the same service endpoints from all
clients. on the browser, this would probably mean having an AJAX
client request services and use the DOM to modify what's presented to
a user. Or you could do what most secondlife.com services today do
which is to have a web server tier that requests the service on the
viewer's behalf, converts it into HTML as a full page and then passes
it to the browser. Or you would have a viewer application requesting
information. Or you would have another server process requesting
information.

it shouldn't matter to the interface exported by the service.

what i think we're talking about is a mechanism for unambiguously
identifying locations in the virtual world as seen from within the
virtual world. i think i have to make this distinction because it's
easy to imagine a world where (like second life today) the mapping
between host and region is non persistent (i.e. - regions change the
hosts they run on.)

you can't use a DNS FQDN + a point in 3d space to identify a location
in the virtual world because you may have multiple regions being
simulated on a single host and as mentioned above, you may get a
different host to region mapping on different days.)

so how do you unambiguously communicate a virtual location from a
server to a client?

Second Life(tm) that is partitioned into regions uses the tuple
{region name, x, y, z} and it is sometimes rendered as "<region
name>/<x>/<y>/<z>". But one of our objectives is to have a single
"virtual world" whose regions are operated by different organizations
and the ability to have completely separate "virtual worlds".

if the mapping between a region and a host is clear, you may not need
to explicitly identify the mapping service. as long as you stayed only
in one virtual world, you would probably be fine. but the moment you
wanted to send an email to someone identifying the location in an
arbitrary world, you're going to run into problems.

what if i set up my own pocket universe with regions Dore, Grignano
and Ahern? Second Life also has these regions, so if i wanted to use
the reference "Dore/128/128/32" as a location to teleport to, i would
have to have a separate region name to service endpoint resolution
service.

so maybe the answer is to use a URL to a service that knows how to map
a region name to a host + the region name + the point in 3space as the
unique identifier for location in space?

it looks ugly, but maybe it would be something like this as the
unambiguous identifier for the  region:

http://example.com/locations?location_x=76&location_y=204&location_z=22&region_name=Levenhall

-cheers
-meadhbh

On Thu, Jan 21, 2010 at 11:33 AM, Han Sontse <[e-mail]> wrote:
> I don't think we can assume a client is the requester.
> If it was a browser, then the mapping service might return
> a rendered map of the area, or even a rendered view
> of the location as an image embedded in a webpage.
>
> http://www.vw.maps.service.tld/?loc=UUID
>
> Or something similar.  The notion here is that
> at some point a client in the world requested the location
> from the mapping service and got the URL back.
>
> How the mapping service manages the UUID mapping to location
> is implementation specific for the VW.   If a client requests this
> the mapping service is going to know that it's dealing with a client,
> rather than a browser.
>
> Han
>
> On Jan 21, 2010, at 11:13 AM, Meadhbh Hamrick wrote:
>
>> dan, i see where you're going with that. here's some comments.
>>
>> i think we're trying to use one mechanism to do multiple things.
>>
>> first, i think we're trying to identify a location in the consensual
>> hallucination of the virtual world. infinity's virtual home at
>> Levenhall/76/204/22 exists in the same apparent location with respect
>> to the surrounding regions despite the fact that the host that
>> simulates that region changes (last i checked, Levenhall was being
>> simulated on sim9809.agni.lindenlab.com.)
>>
>> second, we want to provide unique references to locations for use in
>> protocol transactions.
>>
>> third, we want to provide service endpoints to complete different
>> protocol interactions (teleport, for instance.)
>>
>> my big fear is that if we use one mechanism for everything, we may
>> fail. i think i was thinking of use case number 2 and you're thinking
>> of use case number 3. use case number 1 requires us to think about
>> maps and the layout of regions in the virtual world.
>>
>> so maybe the idea of a URN scheme to identify virtual locations is a
>> good one. maybe something like:
>>
>> urn:vwloc:<region name>:<x>:<y>:<z>
>>
>> (example... urn:vwloc:Levenhall:76:204:22)
>>
>> but the limitation here is that it would imply a single region name to
>> service endpoint mapping service. but maybe that's okay in some cases?
>>
>> in the general case, we want to be able to email a URN like this to
>> someone and without them having prior knowledge of the mapping
>> service, they're able to use the location name to find the service
>> endpoint their viewer will use to visit the location.
>>
>> but.. the service to do the mapping is probably at a service
>> endpoint... so maybe that's the URL we're trying to define.
>>
>> anyway. lotsa options.
>>
>> On Thu, Jan 21, 2010 at 10:23 AM, Dan Olivares <[e-mail]>
>> 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
>
>