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

[Morgaine <[e-mail]>]

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.

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

>
> 1. we're discussing the representation of locations within the virtual
> 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
<[e-mail]>wrote:

> 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 <[e-mail]> wrote:
> > 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.)
> >
> > On Fri, Jan 22, 2010 at 8:02 AM, Meadhbh Hamrick <
> [e-mail]>
> > wrote:
> >>
> >> 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 <[e-mail]>
> >> wrote:
> >> > 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:
> >> >
> >> > I like this idea too, makes a lot of sens. +1
> >> >
> >> > On Thu, Jan 21, 2010 at 10:10 PM, Meadhbh Hamrick
> >> > <[e-mail]> wrote:
> >> >>
> >> >> 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
> >> >>
> >> >
> >> > --
> >> > Jeroen Frans
> >> > Virtual World Technology Specialist.
> >> > TheVesuviusGroup.com
> >> > SL: Frans Charming
> >> > _______________________________________________
> >> > 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
>