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

From: "Hurliman, John" <[email-masked]>
Date: Wed, 20 Jan 2010 14:24:25 -0700

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

---

From: Kari Lippert <[email-masked]>
Date: Thu, 21 Jan 2010 07:34:00 -0500

Here's a start....

To design this, the better question to ask is what is required to uniquely
location a point in a virtual world? The information can always be encoded
with more user-friendly names/references as required.

Name of World
Server
Instance
Region
x-coordinate
y-coordinate
z-coordinate

IMHO I think that would cover it all - but I am not intimately familiar with
the inner workings of all virtual worlds.

Kari

On Wed, Jan 20, 2010 at 4:24 PM, Hurliman, John <[email-masked]>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:
>
>
>
> _______________________________________________
> ogpx mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ogpx
>
>

-- 

http://kjlippert.wordpress.com/
http://community.webshots.com/user/MissGnomer

---

From: Suzy Deffeyes <[email-masked]>
Date: Thu, 21 Jan 2010 07:27:00 -0600

Is it overly confusing to allow specifying  look-at point? That would allow
you to specify a link to a location that orients the user looking in the
correct direction?

The old OGP spec for rez_avatar/place allows it (
http://wiki.secondlife.com/wiki/OGP_Teleport#POST_Interface ), however, I
have not implemented it in the viewer in any way, shape, or form.

Suzy Deffeyes/Pixel Gausman
IBM

On Thu, Jan 21, 2010 at 6:34 AM, Kari Lippert <[email-masked]>wrote:

> IMHO I think that would cover it all - but I am not
> intimately familiar with the inner workings of all virtual worlds.
>
> Kari
>
>
>
>>  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:
>>
>>
>>

---

From: Kari Lippert <[email-masked]>
Date: Thu, 21 Jan 2010 08:35:36 -0500

Orientation or heading is certainly a good addition. If not implemented in a
world it can be ignored!

Kari

--

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 21 Jan 2010 08:37:21 -0500

I generally view URI schemes as subservient to protocols: The URI  
specifies what server you talk to and what you send it.  For example, <http://example.com/foo 
 > tells you to send a request to example.com with "/foo" as the  
request URI.  So I would think that the elements of the URI would come  
out of the fields that we end up having in the protocol, rather than  
some information model that we come up with specifically for the URI.

--Richard

On Jan 21, 2010, at 8:27 AM, Suzy Deffeyes wrote:

>
> Is it overly confusing to allow specifying  look-at point? That  
> would allow you to specify a link to a location that orients the  
> user looking in the correct direction?
>
> The old OGP spec for rez_avatar/place allows it (http://wiki.secondlife.com/wiki/OGP_Teleport#POST_Interface 
>  ), however, I have not implemented it in the viewer in any way,  
> shape, or form.
>
> On Thu, Jan 21, 2010 at 6:34 AM, Kari Lippert  
> <[email-masked]> wrote:
> Here's a start....
>
> To design this, the better question to ask is what is required to  
> uniquely location a point in a virtual world? The information can  
> always be encoded with more user-friendly names/references as  
> required.
>
> Name of World
> Server
> Instance
> Region
> x-coordinate
> y-coordinate
> z-coordinate
>
> IMHO I think that would cover it all - but I am not intimately  
> familiar with the inner workings of all virtual worlds.
>
> Kari
>
>
>
> On Wed, Jan 20, 2010 at 4:24 PM, Hurliman, John <[email-masked] 
> > 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:
>
>

---

From: Kari Lippert <[email-masked]>
Date: Thu, 21 Jan 2010 08:45:20 -0500

I agree and I see this as a precursor discussion for things that must be
included in the information model!

Kari

On Thu, Jan 21, 2010 at 8:37 AM, Richard L. Barnes <[email-masked]> wrote:

> I generally view URI schemes as subservient to protocols: The URI specifies
> what server you talk to and what you send it.  For example, <
> http://example.com/foo> tells you to send a request to example.com with
> "/foo" as the request URI.  So I would think that the elements of the URI
> would come out of the fields that we end up having in the protocol, rather
> than some information model that we come up with specifically for the URI.
>
> --Richard
>
>
>

--

---

From: Carlo Wood <[email-masked]>
Date: Thu, 21 Jan 2010 17:33:52 +0100

> How would this change to accommodate a location in any region domain?

This is not an URI because an URI would start with the protocol name.

Wouldn't it be nice if a location URI would have a clear meaning
even if it was mentioned in an email (or anywhere, thus)?

Even if vwrap:// isn't a standard yet, I think URI's should be like http://
and file://.

So,

vwrap://secondlife.com/region%20name/x/y/z

seems a candidate?

-- 
Carlo Wood <[email-masked]>

---

From: Carlo Wood <[email-masked]>
Date: Thu, 21 Jan 2010 17:55:45 +0100

On Thu, Jan 21, 2010 at 07:34:00AM -0500, Kari Lippert wrote:
> location a point in a virtual world? The information can always be encoded with
> more user-friendly names/references as required.
> 
> Name of World
> Server
> Instance
> Region
> x-coordinate
> y-coordinate
> z-coordinate

There are going to be a lot of "worlds" (an arbitrary number).
The best way to easily garantee uniqueness is to use some domainname
that is associated with that world, ie, "example-world.com".
I think that this should (indeed) be the first part of the URI,
or rather, that the first part of the URI should be world-unique.
In order not to confuse the domainname with any other service
of that domain, the URI should have a leading part that specifies
what it is, hence:

vwrap://example-world.com/...whateverelse...

Also, "Server" and "Instance" would be rather optional, since they
do not exist in the virtual world. I suppose it would be better
to put such things in the hostname, ie:

vwrap://server1-instance2.example-world.com/region/x/y/z

---

From: Meadhbh Hamrick <[email-masked]>
Date: Thu, 21 Jan 2010 10:05:07 -0800

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

---

From: Dan Olivares <[email-masked]>
Date: Thu, 21 Jan 2010 13:23:16 -0500

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-----

{

 region_protocol: string,
 region_address : string,
 region_port: int,
 region_name : string,

<?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,

<?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

---

From: Joshua Bell <[email-masked]>
Date: Thu, 21 Jan 2010 10:45:52 -0800

I think the point is that rather than defining a URI scheme for
VWRAP-implementing virtual worlds in general - which might imply namespace
management and/or conventions and organization (i.e. you MUST have named
regions, you MUST use x/y/z coordinates, you MUST ...) we allow the service
provider to offer any URI scheme but standardize on a payload that is
compatible with the place-agent-in-region part of VWRAP.

For example, Linden Lab offers SLurl.com for Second Life addressing. The
fact that visiting http://slurl.com/Ahern/128/128/20 provides a redirect to
secondlife:///Ahern/128/128/20 (and the SL client is registered to handle
the secondlife: scheme) is an implementation detail. Implementing new
schemes is frowned upon. The preferred approach is to return a document with
the correct Internet Content Type and have an application register to handle
the content type. (i.e. what Meadhbh said!)

So we *still* have URIs, but the URIs are real honest-to-goodness HTTP(S)
URLs that return actual documents. (You can imagine a trivial redirect site
that transforms the URL structure into an LLSD document for a known
parameter set.)

On Thu, Jan 21, 2010 at 10:23 AM, Dan Olivares <[email-masked]> wrote:

> a

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 21 Jan 2010 14:00:58 -0500

Meadhbh,

Based on your LLIDL, how do I figure out what VWRAP server (Region  
Agent?) to contact?  Do we need to add a host:port?

If the information really is as succinct as you say it is, there's not  
really much difference between the approach you describe and a URI  
scheme.  Kind of the difference between the "geo" URI scheme  
(<geo:lat,long,alt>) and an HTTP URI pointing to a GeospatialML  
document, in fact, the geo URI spec defines an equivalence <http://tools.ietf.org/html/draft-ietf-geopriv-geo-uri 
 >.

--Richard

On Jan 21, 2010, at 1:05 PM, Meadhbh Hamrick wrote:

> On Wed, Jan 20, 2010 at 1:24 PM, Hurliman, John <[email-masked] 
> > wrote:

---

From: Dan Olivares <[email-masked]>
Date: Thu, 21 Jan 2010 14:05:06 -0500

If you're saying that implementing new schemes 'vwrap://' is frowned
upon by the IETF, then I can see where you are going with this.  You
simply think we'll have a better chance of getting through the
standards process if we use a file with an appropriate content type.

The issue for me, really, is the assumption that mapping service
slurl.com is assumed to be the region domain based on the LLIDL.
{
 region_name : string,
 location : [ int, int, int ]
}

There isn't enough information for a client application to determine
otherwise in that LLIDL.    Even for Linden Labs' purposes, it would
be reasonable to have a page at sLURL send a LLIDL structure like:
{
 region_domain : string,
 region_name : string,
 location : [ int, int, int ]
}

that would be serialized like;

  <key>region_domain</key>
  <string>http://agni.secondlife.com/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>

otherwise..     a good faith client would have to assume slurl.com as
the region domain because there are no other references to region
domains..  It couldn't assume agni.   Additionally, that wouldn't work
for 'hyperlinking' in world because the file with the proper content
type, metaphysically, couldn't be on the agent domain in every
circumstance unless you're thinking of adding another layer of
complication and single point of failure where by each region domain
implements it's own SLURL mapping service and a method of dealing with
hyperlinks to it's regions by way of URL parameters or some other
variable method and outputs the shortened LLIDL version and the
content type handler assumes the agent domain is serving the file.

Daniel Olivares

---

From: Han Sontse <[email-masked]>
Date: Thu, 21 Jan 2010 11:05:49 -0800

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

---

From: Dan Olivares <[email-masked]>
Date: Thu, 21 Jan 2010 14:11:51 -0500

Scrach that last agent domain in my last e-mail and replace it with
region domain in the following statement,
"and the content type handler assumes the agent domain is serving the file."

It should have been
"and the content type handler assumes the region domain is serving the file."

Daniel Olivares

---

From: Meadhbh Hamrick <[email-masked]>
Date: Thu, 21 Jan 2010 11:13:28 -0800

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.

---

From: Meadhbh Hamrick <[email-masked]>
Date: Thu, 21 Jan 2010 11:32:45 -0800

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 <[email-masked]> 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,
>  user cannot see all of the axes in use to describe the unique position, the
> I'd like to suggest that we find a VWRAP appropriate way for a client to
> discover what the
> While I don't know exactly how WoW manages location specification I do know
> that
> 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
> 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
> 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
>

---

From: Han Sontse <[email-masked]>
Date: Thu, 21 Jan 2010 11:33:58 -0800

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

---

From: David W Levine <[email-masked]>
Date: Thu, 21 Jan 2010 14:35:42 -0500

This is a very cogent point. While the biggest use case for the VWRAP 
services is "clients" its not the only one. 

[email-masked] wrote on 01/21/2010 02:33:58 PM:

> [image removed] 
> 
> Re: [ogpx] URI schema for virtual world locations?
> 
> Han Sontse 
> 
> to:
> 
> Meadhbh Hamrick
> 
> 01/21/2010 02:34 PM
> 
> Sent by:
> 
> [email-masked]
> 
> Cc:
> 
> "[email-masked]"
>

---

From: Han Sontse <[email-masked]>
Date: Thu, 21 Jan 2010 12:12:10 -0800

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:

>> VWs in
>> coordinate
>> ability
>> loads
>> involved to
>> region of
>> providers to
>>>>> URI schema for a location in a virtual world (home location,  
>>>>> requested
>>>>> login

---

From: Meadhbh Hamrick <[email-masked]>
Date: Thu, 21 Jan 2010 12:38:26 -0800

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

---

From: "Hurliman, John" <[email-masked]>
Date: Thu, 21 Jan 2010 13:54:37 -0700

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

+1

---

From: Joshua Bell <[email-masked]>
Date: Thu, 21 Jan 2010 13:06:00 -0800

Assumptions make me sad - I'd want to be able to explicitly specify the
region service endpoint in the data coming back.

This is necessary in the case where you click on a link in a Web browser
which returns a content-typed blob; the blob could be handed off to a VWRAP
viewer which has no idea where the blob came from.

On Thu, Jan 21, 2010 at 11:11 AM, Dan Olivares <[email-masked]> wrote:

> to

---

From: Meadhbh Hamrick <[email-masked]>
Date: Thu, 21 Jan 2010 13:10:04 -0800

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 <[email-masked]> wrote:
> 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
>
>>> know
>>> space
>>>>> On Wed, Jan 20, 2010 at 1:24 PM, Hurliman, John
>>>>> <[email-masked]>
>>>>> wrote:
>>>>>>

---

From: Carlo Wood <[email-masked]>
Date: Fri, 22 Jan 2010 01:21:37 +0100

> standards process if we use a file with an appropriate content type.

Actually... I take back my proposal to use vwrap://...

After all that first part (vwrap) means that that is the
protocol used. So, such an URI would be used to establish
a connection over which the VWRAP protocol is used.
That was not the case though.

Meadhbh is right, the correct way is to use http:// and
have the page return a different content type.

The actual format can be XML for the reasons given.
The actual data should be everything that is needed (for vwrap)
to allow someone to connect there (*just* a region name wouldn't
be enough, you also need to know which world it is).

---

From: Frans <[email-masked]>
Date: Fri, 22 Jan 2010 15:25:32 +0100

I like this idea too, makes a lot of sens. +1

On Thu, Jan 21, 2010 at 10:10 PM, Meadhbh Hamrick <[email-masked]

> http//
> util.vaak.lindenlab.com/services/map?location_x=128&location_y=128&location_z=32&region_name=Ahern
>    <uri>
> http://sim1.vaak.lindenlab.com/c/0953E063-5B31-4B62-B218-A7C0CE1FC391
> </uri>
>    <key>map_tile</key>
>    <uri>
> http://sim1.vaak.lindenlab.com/c/4AFA1BAF-4FAD-45A5-A683-6244BC81A660
> </uri>
>  </map>
> </llsd>
>
-- 
Jeroen Frans
Virtual World Technology Specialist.
TheVesuviusGroup.com
SL: Frans Charming

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 22 Jan 2010 10:22:02 -0500

It's not clear to me why the protocol needs to define coordinates,  
especially given that different servers might have different notions  
of place.  One server might think of space in terms of coordinates in  
meters, another in polar coordinates, another in terms of polygons  
that represent some construct known only to the server.

So when we're talking about referring to points in space, it seems  
like it would make sense to have two parts: One piece of information  
that gets you to the right server, and one that tells the server what  
location is being referenced (in whatever frame it thinks in).

To make an analogy, in the HTTP URI <http://example.com/this/is/a/ 
path>, the authority part "example.com" gets you to the right server,  
and the meaning of the path component "this/is/a/path" is completely  
up to the server (it can be opaque to the user).

--Richard

On Jan 22, 2010, at 9:25 AM, Frans wrote:

> http//util.vaak.lindenlab.com/services/map? 
> location_x=128&location_y=128&location_z=32&region_name=Ahern

---

From: Meadhbh Hamrick <[email-masked]>
Date: Fri, 22 Jan 2010 08:02:12 -0800

it's important because one of the functions of the protocol will be
for clients to inform servers where they wish their avatars to appear
in the virtual world. virtual objects will be moving as well, and
simulators will need to communicate with user agents the moral
equivalent of "box number 5 just moved to location <x,y,z>."

VWRAP is a protocol for interaction between systems that have
characteristics similar to OpenSimulator and Second Life. Both systems
use meters in a rectangular coordinate system to describe position.

There has been discussion in the past about supporting multiple
coordinate systems, but the implementers believed it would introduce
unneeded complexity. Requiring that ALL compliant systems support ALL
possible representational systems seemed like an invitation to
incompatibility.

VWRAP does not mandate what coordinate system your implementation uses
internally, it only mandates what coordinate system you use to
communicate with other systems. If you wish to use polar coordinates
measured in femtoparsecs in your implementation, that is your
business. but when it's time to communicate with the outside world
(using VWRAP), you'll have translate into/out of meters in a
rectangular coordinate system.

this is not because we're rectangular bigots, it's because many of us
believe that picking a single representational system will reduce
complexity of the protocol.

-cheers
-meadhbh

On Fri, Jan 22, 2010 at 7:22 AM, Richard L. Barnes <[email-masked]> wrote:
> especially given that different servers might have different notions of
> place.  One server might think of space in terms of coordinates in meters,
> another in polar coordinates, another in terms of polygons that represent
> some construct known only to the server.
> So when we're talking about referring to points in space, it seems like it
> would make sense to have two parts: One piece of information that gets you
> to the right server, and one that tells the server what location is being
> referenced (in whatever frame it thinks in).
> To make an analogy, in the HTTP URI <http://example.com/this/is/a/path>, the
> authority part "example.com" gets you to the right server, and the meaning
> of the path component "this/is/a/path" is completely up to the server (it
> can be opaque to the user).
>
> --Richard
>
>
> On Thu, Jan 21, 2010 at 10:10 PM, Meadhbh Hamrick

---

From: Joshua Bell <[email-masked]>
Date: Fri, 22 Jan 2010 08:35:34 -0800

Agreed. When something needs to be specified, it should be done to enable
interoperation between actual systems and can be implemented and proven by
running code. If coordinates-within-regions are necessary to specify, x/y/z
coordinates in meters with IEEE 754 64-bit floats appear to be completely
sufficient for current systems.

That said, I think part of the challenge for the VWRAP WG is to determine
what can be left *unspecified* yet *not* get in the way of interop
envisioned by this group. (Which is one of the topics I want to discuss at
length in Anaheim). As an example, if there are places where data can be
relayed between two endpoints by a third party without specification in the
protocol itself, and the burden is on those endpoints to have out-of-band
agreement on the format, that simplifies VWRAP and enables scenarios we
hadn't thought of. (I'm not sure that's applicable to this example, just
throwing it out.)

---

From: Meadhbh Hamrick <[email-masked]>
Date: Fri, 22 Jan 2010 11:13:46 -0800

cool. before leaving this topic though, i'd like to synthesize the
messages in this thread and try to make some assertions regarding the
problem domain of virtual world locations.

i think these are non-controversial.

1. we're discussing the representation of locations within the virtual
world as expressed in the protocol.

1.1. individual implementations may choose to define points in space
using a representational system of their choosing, but the protocol
will define at least one default representation that all systems
should comprehend.

1.2. "locations within the virtual world" are represented as points in
a multi-dimensional space. points are partitioned into "regions" for
administrative and/or performance reasons.

1.3. there may be two forms of location representation: absolute
position within the virtual world (as denoted by a single point in
space) or relative to the origin of a region.

1.4. the statement above (1.3) implies there is a public service
available to map between points in the absolute space of the virtual
world and points relative to a region.

2. representations of locations in a virtual world are used for at
least these purposes:

2.1. to define the origin and bounds of a region in a virtual world.

2.2. to define the location of an object in the virtual space.

2.3. to define the destination of a teleport request.

2.4. to define the destination of spatial chat / voice

3. "the" representation of locations in the virtual world should be
extensible to allow implementers and deployers the ability to add
experimental or implementation specific information to the locational
reference.

3.1. implementations that process location references should retain
location data they do not recognize. that is, an implementation that
receives a location reference including information it doesn't
understand, it should not discard that information. rather, it should
retain that information in case it must pass on that location
reference to an implementation that does recognize it.

4. the protocol must not REQUIRE a single service that maps between
points relative to the origin of the "world" and points relative to
the origin of an individual region.

On Fri, Jan 22, 2010 at 8:35 AM, Joshua Bell <[email-masked]> wrote:
> On Fri, Jan 22, 2010 at 8:02 AM, Meadhbh Hamrick <[email-masked]>
> wrote:
>>

---

From: Carlo Wood <[email-masked]>
Date: Sat, 23 Jan 2010 01:36:37 +0100

> world and points relative to a region.

It is not true that the relative position of any two arbitrary
regions is known. For example, some world could consist of
of planets in solar systems and some would simply be too far
apart to use coordinates in meters. Another example are
the islands of private sims in SL.

Hence, it makes more sense to limit coordinates to a Cartesian
coordinate system relative to a given region, and be have
a public service that maps region name pairs to a relative
position vector v(name1,name2), or returning nil if they are
not in the same space.

The distance between {name1, v1}, where v1 = {x1,y1,z1},
and {name2, v2} is then v(name1, name2) + v2 - v1.

That way a world is not obliged to have one single space
where in every region must have a place.

Also, putting every region in one region will likely
lead to this 2D plane with regions and a z-coordinate
with a range equal to that of each region: a flat world
(like SL). I hope everyone knows that ANY example that
breaks a protocol is prove that the protocol is wrong ;),
so here it goes: someone might want to create "ring world"
(http://en.wikipedia.org/wiki/Ringworld), where the
rings exists of square regions, and the diameter of the
ring is too large to really want to use it. Such a world
could not very easily map it's world positions to a
flat one (or even x/y/z, without getting really large
and seemingly random numbers).

A better approach therefore seems to be:

A Cartesian coordinate system for one region at a time.
A map from region names to a 2-dimensional *map* coordinates,
where the map coordinates might have any arbitrary relationship
to world coordinates (being irrelevant), including the
notion that two regions might not be in the same space.

This would allow painting a map on a 2D surface (which can
be used to explore and retrieve LM's from), but it would
NOT allow to calculate the (real 3-D space) distance between
points.

1.3. there may be two forms of location representation:
map position (longitude/latitude) that give regions in a
given space, a place on a map, and cartesian coordinates
relative to the origin of a region (x,y,z).

1.4. the statement above (1.3) implies there is a public service
available to map between the {space, longitude, latitude}
"map coordinates" and points relative to a given region:

{space, longitude, latitude} <---> {region name, x, y}

---

From: Carlo Wood <[email-masked]>
Date: Sat, 23 Jan 2010 01:53:39 +0100

> coordinate system relative to a given region, and be have

and have*

> position vector v(name1,name2), or returning nil if they are

Later I got back from this idea, see below.

> and {name2, v2} is then v(name1, name2) + v2 - v1.

This will thus not be possible (nor needed), see below.

> Also, putting every region in one region will likely

in one space*

> breaks a protocol is prove that the protocol is wrong ;),

proof*

> rings exists of square regions, and the diameter of the

ring*

> flat one (or even x/y/z, without getting really large

Rather, to a 3D one (regions would be upside down
relative to others).

> {space, longitude, latitude} <---> {region name, x, y}

In the case of Second Life, there is only one 'space' (rather,
one map), so 'space' would always be the same value (ie '0').

A different space means a different map, and also that you
can't walk there, only teleport. There is therefore little
difference between two different spaces within one VW (as in
"run by one authority") and two different VW's (that allow
teleporting between them).

PS Re RingWorld... it WOULD be kinda cool is you could
   look 2 or three sims far, and anything beyond that
   would be "map"... in a ring :). If you'd look up,
   you'd see the ring, and you could zoom in like on
   a real map (and double click to teleport there).
   Heheh.  That would require some viewer-side support
   though.

---

From: Meadhbh Hamrick <[email-masked]>
Date: Fri, 22 Jan 2010 17:48:32 -0800

and some comments.. discuss? or all we all good?

On Fri, Jan 22, 2010 at 11:13 AM, Meadhbh Hamrick
> will define at least one default representation that all systems

based on discussion on the list, i think the practical ramification of
this statement means "the protocol will represent points in the
virtual world using 3 64 bit IEEE 764 floats denoting the x,y,z
coordinates (in metres) in a rectangular coordinate system.

we do this because we don't want to force every implementation to
support a number of representational systems. points in space can be
represented in a number of ways. parsecs in a spherical coordinate
system would be an excellent representational system if we were
building a simulation of stars in a galaxy. but the main use case
we're thinking of is spaces for virtual people on people scales using
fixed, familiar coordinate system.

that being said, we could probably easily accommodate developers whose
use cases call for different coordinate systems in some ways. an
example was given where the "coordinate system" could be specified as
a parameter to a virtual world.

implementers should understand the ramification of this decision,
however. the more abstract the protocol, the more work implementers
will have to cover all conceivable situations. at the end of the day,
large parts of the protocol needs to be consumed by a client
application which will render a representation of the virtual world.
if you deploy a grid that specifies points in space using something
other than the default, you will greatly limit the ability of client
rendering software to make sense of the points you specify.

so... the primary use case (people on people scale) is pervasive
enough to select it as the default and to require users of other
representational systems to convert location references in the local
representational system to the network standard for use in the
protocol.

> administrative and/or performance reasons.

IMHO, "locations within the virtual world" highlights the point that
the virtual world has a geometry that may be distinct from the
geometry of the hosts used to simulate it.

for example. imagine that you're at "infinity is full of stars" (
http://slurl.com/secondlife/Levenhall/76/204/22 ), and you're looking
into the Longfellow region immediately north of Levenhall. the
relationship between Longfellow and Levenhall is independent of the
relationship of the hosts on which they are simulated.

this is to insure that location references persist across the purely
administrative action of moving the region to a new simulator host.
from the point of view of an avatar in the virtual world,
Levenhall/76/204/22 should always have the same relation to
Longfellow/128/128/20 (assuming the position of these regions within
the virtual world is not changed.)

> space) or relative to the origin of a region.

Is this reasonable? Second Life frequently represents points at
<region name>/<x>/<y>/<z>. But the virtual world also defines an
"absolute space" into which regions are placed and it is possible to
convert between the two. The region-relative form is preferred because
it's relatively easy to convert between region name and FQDN of the
host simulating the region. Second Life residents are also socialized
to understand that the region is an important administrative entity.
Neither of these statements may be true of all VWRAP implementations.

> world and points relative to a region.

Maybe the mapping between region and "space" should be the canonical
definition of a "grid" or a "virtual world" or an "instance." It does,
however, bring up the point again that in VWRAP, it's not illegal for
one region to exist in two virtual worlds. this is a policy decision
that is left to individual deployers.

it's easy to conceive of a situation where region A exists in "world
1" and "world 2". if the placement of regions inside a "grid" or
"world" is in inherent function of a virtual world, then it's possible
for region A to be adjacent to a different set of regions in the two
different worlds. that is, in world 1, region B may be directly north
of region A while in world 2, region C may be directly north of region
A.

the trust model we've been talking about defines a relationship
between an agent domain and a region domain. it's possible that User 1
who authenticates with agent domain 1 which has a trust relationship
with world 1 and User 2 authenticating against AD2 which has a trust
relationship with world 2 will see different things when they are both
present in region A and look north.

in other words, two people in the same place in "the" virtual world
may see radically different things under the same circumstances.
people should understand that this MAY not be a welcome outcome for
some participants.

proceed with caution.

> the origin of an individual region.

i.e. - VWRAP should allow deployers to create a virtual world that is
independent of Second Life.

---

From: "Hurliman, John" <[email-masked]>
Date: Fri, 22 Jan 2010 19:01:54 -0700

The obvious use cases I can think of that would fall within a "Second Life like world" would be a world that uses a single coordinate system to describe positions in the world and has no concept of individual regions (or from another perspective, every simulation node simulates a portion of a single very large region) and a true 3D world that has regions that exist above and below other regions instead of the flat SL world. If I'm reading this right, both of those models would be supported, so I'm still +1 on this.

John

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Meadhbh Hamrick
> Sent: Friday, January 22, 2010 5:49 PM
> To: Joshua Bell
> Cc: [email-masked]
> Subject: Re: [ogpx] URI schema for virtual world locations?
>

---

From: "Infinity Linden (Meadhbh Hamrick)" <[email-masked]>
Date: Fri, 22 Jan 2010 18:18:41 -0800

> the islands of private sims in SL.

are we saying the same thing?

in SL, we don't reckon the position of a region by it's relative
location to other regions, we reckon it relative to an absolute
coordinate system. i'm 99% certain that OpenSim does the same thing by
default.

in SL, the absolute position of a sim IS known, even if it's a single
island region.

that being said, it doesn't necessarily need to be this way.

> position vector v(name1,name2), or returning nil if they are

hmm.. this doesn't make more sense to me. having a "grid" or "virtual
world" with an origin and an extent that contains regions (each with
their own origins and extents) seems to be the simplest way to handle
this.

the reason i say this is that if i'm a viewer developer, and i have an
avatar that's standing close to a region border, i'm going to want to
be able to determine which regions intersect with my viewing cone.  it
just seems easier to code for me to have a big table of regions'
origins and extents.

at the end of the day, however, maybe we can get away with not
specifying an absolute coordinate system, but instead specify a
service that provides a list of regions that intersect with an agent's
viewing cone.

since the service that maps between absolute positions in the virtual
world and relative positions in a region would presumably know about
the region you're in, you could give it your location relative to the
origin of the region you're in, and if it needed to, it could
determine the global coordinates itself. heck, that might even be more
secure.

i would personally be a little wary about making this a service that
lives on a particular region host. but maybe there's a compelling
argument for the viewer to ask the particular region for the endpoint
to this service?

> and {name2, v2} is then v(name1, name2) + v2 - v1.

but how do you get v(name1, name2)? do you store the offsets for each
pair of regions in a grid?

> and seemingly random numbers).

this is an example of using a cylindrical coordinate system.

or, you could simply cheat and build a special viewer that knows that
space is supposed to be cylindrical and have the viewer stitch
together the ends of a line of regions.

> notion that two regions might not be in the same space.

what if i wanted to have two regions, one on top of another? SL
doesn't do that now, but if we're going to allow ringworlds, shouldn't
we allow regions to sit atop each other?

---

From: Morgaine <[email-masked]>
Date: Sat, 23 Jan 2010 05:47:06 +0000

It's important to be careful with language, or we may be in danger of
retreading earlier problems which arose through (mis)treating "virtual
world" as a unitary thing and goal.

> world as expressed in the protocol.

A location may be within the current world or in a different world.  VWRAP
targets both types of deployment, and of course includes interop between
different VWRAP-based worlds as an important requirement.  The issues are
different in each case.

When talking about coordinates and landmarks, the distinction between one
world and another world becomes crucial, since they may have non-unique
region names for example. We may be in one world and be given a landmark to
another (an extremely common use case no doubt), and we have to be able to
use that "foreign" landmark in a teleport despite its meaning being
unresolved in the context of our current world.  That requires a level of
indirection.

The suggestion that a world be consulted to interpret a location specified
within it is a very good one (implying some kind of region lookup service),
because only the world can ever know where a particular named region
resides, and only the region can know where a particular address is located.
Address mapping is a part of region policy, just as region mapping is part
of a given world's policy.  It's certainly not up to us to dictate where a
region locates the origin of its cartesian coordinate system for example.

Our protocol should not prescribe anything about worlds unless there is no
reasonable alternative, since everything that we hardwire limits the range
of deployments and reduces diversity and innovation in the worlds
themselves.

In the case of location descriptors, there are many reasonable alternatives
to hardwiring locator semantics, such as the suggested per-world lookup
service.  That idea has the great merit of extensibility too --- for
example, space-based worlds will be able to return scaling factors so that
astronomical distances between planets are handled using sensible units
rather than meters, which is important for usability.

I support the idea of asking a world:  "Here's a location reference, please
tell me everything that I need to know to be able to TP to the referenced
spot".  Note that this allows location references to be *opaque data* too,
which is a highly desirable property in some important use cases where
information leakage needs to be avoided.

Morgaine.

===================================

On Fri, Jan 22, 2010 at 7:13 PM, Meadhbh Hamrick
<[email-masked]>wrote:

> of
> like
> >> > it
> >> > To make an analogy, in the HTTP URI <
> http://example.com/this/is/a/path>,
> >> > the

---

From: Carlo Wood <[email-masked]>
Date: Sun, 24 Jan 2010 14:59:55 +0100

I pressed the 'send' button too soon, but almost immediately followed
up with a reply to myself (where I more or less took back the first
part, that you comment on ;).

My point was, there is only a need for a 3 dimensional cartesian coordinate
system really, relative to a region.

In order to be able to show map, it should be possible map regions
to some 2 dimensional coordinate system.

By using a global 3 dimensional *cartesian* coordinate system,
and do the latter mapping by projecting along the z-axis, we'd
force every world to be flat.

If that is what we decide for, so be it. But if we want to avoid
getting only flat worlds for some reason then we have two options:

* Either add support for other coordinate systems (cylindrical, polar...)

or 

* Let go of the "simple" way that local 3D coordinates are mapped
  to the 2D 'map' coordinates.

If on top of that we want to accommodate the fact that some regions
are not connected at all (you can't fly or walk from one to the
other: they do not have any intuitional or logical relative position),
we need to add the notions of 'spaces' (mathematical word), or
maybe call it 'map' as that is what it will boil down to: separate
maps of connected regions (I recall having posted a proposed word
for that for communication purposes: continents).

Hence my proposal for points 1.3 and 1.4:

{space/map, longitude, latitude} <---> {region name, x, y}

I have no objection, not too strong anyway ;), against
continents being flat on the map, only allowing curved
land through special browsers. The reason for that is
that I think that otherwise it's just too hard to create
and show a map, something not worth the effort at this
point, not even during the design of this standard :/

Note that by setting "space/map" to a constant, this
extended proposal is completely consistent with how
SL currently works (one big map, and {longitude, latitude}
being the global coordinates). Yet, it would discourage
using {x, y, z} for global coordinates, but shows that
it's needed / better to use {region, x, y, z} for
locations, or alternatively {space/map, longitude, latitude, z}.

---

From: Kari Lippert <[email-masked]>
Date: Sun, 24 Jan 2010 09:53:32 -0500

When modeling information with disparate groups, this kind of discussion is
healthy. There is still an issue here with what each currently known service
requires, and what the science fiction types in the group think they might
require in future yet-to-be-built worlds. There have been a few proposals
for how to handle that but it's not clear to me that the solution
(require cartesian coordinates) will satisfy all comers. I'd like to propose
a very simple stating, by those who know, of how current worlds specify a
location of an avatar or object in their world. There may be another
solution (along the lines of a transformation service mentioned previously)
hiding out there. Certainly in the information I suggested initially there
needs to be added which world!  Can we get world-specific definition for
"location" from this list? Are there others that are not represented by
membership?

I'd also like to continue this discussion in the conceptual space - figuring
out implementation is a good exercise to test a solution but if done prior
to arrival at a solution it can hamper an exploration of the possible.

Kari

--

---

From: Joshua Bell <[email-masked]>
Date: Mon, 25 Jan 2010 11:59:50 -0800

> system really, relative to a region.

I tend to agree. The more that can be region-centric, the better. If a
provider of a collection-of-regions wants to define relationships between
even disconnected locations, that shouldn't be precluded, but it doesn't
appear *necessary*...

That said, I believe it adds complexity to region crossings. In SL, an agent
crossing between regions maintains global coordinates throughout. The agent
is also notified about things happening across region boundaries with
coordinates that would be outside the region bounds. This will probably make
code for hand-offs and/or the scene graph more intricate.

> to some 2 dimensional coordinate system.
Interesting question: is this part of VWRAP or not? Is there a need for
standards around mapping, or is that just a feature which can be provided in
other ways (e.g. web-based UI) that produces the URIs (which are
specifically URLs to resources containing region connection information, as
this thread suggests) necessary to "go there"?

(This is part of the topic I want to cover in Anaheim.)

---

From: Morgaine <[email-masked]>
Date: Tue, 26 Jan 2010 22:45:58 +0000

On Mon, Jan 25, 2010 at 7:59 PM, Joshua Bell <[email-masked]> wrote:

>
> That said, I believe it adds complexity to region crossings. In SL, an
> agent crossing between regions maintains *global coordinates* throughout.
> The agent is also notified about things happening across region boundaries
> with coordinates that would be outside the region bounds. This will probably
> make code for hand-offs and/or the scene graph more intricate.
>

Given the arbitrary sizes and shapes of interoperating regions in VWRAP
worlds, it's worth stating that it will not be possible to maintain a global
coordinate space that's congruent with region coordinate spaces, even if we
wanted to.

Adjacently tiled regions are necessarily going to have to adopt a relative
addressing approach when dealing with their neighbors, and never assume any
particular layout of other regions' coordinate spaces.  Any such assumptions
would generally be wrong anyway, except for uniformly designed region spaces
which is a special case.  Flexible relative coordinate handling will be
important in this area, since to disallow adjacent region tiling unless
neighbors employ the same coordinate layout and orientation would be far too
restrictive for widespread interop.

Fortunately it's not hard to do this flexibly with just a little more
arithmetic.

Morgaine.

======================================

On Mon, Jan 25, 2010 at 7:59 PM, Joshua Bell <[email-masked]> wrote:

> That said, I believe it adds complexity to region crossings. In SL, an
> agent crossing between regions maintains global coordinates throughout. The
> agent is also notified about things happening across region boundaries with

---

From: Meadhbh Hamrick <[email-masked]>
Date: Tue, 26 Jan 2010 16:20:05 -0800

i guess that's true (that the more we have that's region oriented the
better.) the two uses of locations i'm thinking about now are: a)
specifying the endpoint of a teleport and b) specifying a location so
a client can retrieve information about the location (map tile, how
many avatars are present, human friendly region name, etc.)

if we assume a service that can convert a region name into a URL to
act as an endpoint for teleport, we could get away without a global
coordinate system. and heck, you don't absolutely NEED that service,
you only need it if you want to convert something like
"Levenhall/128/128/32" into a URL to complete a teleport request.

-cheers
-meadhbh