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

[David W Levine <[e-mail]>]

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


[e-mail] 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:
> 
> [e-mail]
> 
> Cc:
> 
> "[e-mail]"
> 
> 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
> 
> _______________________________________________
> ogpx mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ogpx