Kind of crazy idea here, but how is 'landmarks' actually stored on the server and used by the client? Shouldn't we be able to store grid and region endpoint in a landmark? I mean, if the landmark contains the region name, it could just as well be stored with target grid and/or region endpoint in it as well? If the client only uses an uuid, it should be requesting that conversion from the region, which could in turn use the users home grid servers to resolve the uuid request into more metadata - as the landmark was originally created on that grid. (yes, that could, in theory, mean that person A clicking on a landmark in region B would cause B to talk to home grid C that will access originating grid D to resolve the actual endpoint and things like that, but hey - think of the possibilities!Best regards,Stefan AnderssonTribal Media AB
Date: Sat, 31 Jan 2009 11:12:08 -0800From: [email protected]: [email protected]: Re: [Opensim-dev] TP protocol handleForgot to say this.If you want to experience this right now without installing, you can try it in UCI's regions in OSGrid, "UCI Welcome" and "UC Irvine".Kyle wrote: Amazing! Cannot wait to try it soon.... -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Cristina Videira Lopes Sent: Saturday, January 31, 2009 1:49 PM To: [email protected] Subject: Re: [Opensim-dev] TP protocol handle Thanks all for the pointers. I now understand a lot better what these handles are all about, and I've done the first step into pervasive hyperlinking within OpenSim. Starting in r8193, if you're in an HG-enabled region, you'll be able to dynamically link sims, and TP there, in any one of these ways (and probably more) 1) Type for example secondlife://ucigrid04.nacs.uci.edu:9007/ in the chat box, pull up the chat history and click on that link 2) Pull up the map and search for things like ucigrid04.nacs.uci.edu:9007 3) Using the embedded browser visit pages that have links like secondlife://ucigrid04.nacs.uci.edu:9007/ (there's one up at http://www.ics.uci.edu/~lopes/hypergrid/test.html) What I've done is to take advantage of the viewer's existing machinery, especially its interpretation of secondlife:// handles, which expect a region name to follow. When that name is not found in the local grid, this new code kicks in, and does the magic. This doesn't address the launching of the viewer, which is a separate issue, and one that slurl and similar mechanisms like rezzme:// try to address. What it does is, after you're already logged in soomewhere, you can go hypergriding around in a very easy way, all within the viewer's capabilities. The static link-region command and uploads over the web, is still very useful because it supports permanent links. The ones I added are not (intended to be) permanent, they (will) come and go. Feedback welcome! Crista Cristina Videira Lopes wrote: Hi, I want to take HG TPs to the next logical step and support dynamic links, that is, the ability for the user to simply click on something like this http://ucigrid04.nacs.uci.edu:9003/ and be teleported there from anywhere on the Metaverse. The question is: what should these handles look like? I see a variety of protocol handles out there, and I confess I don't understand entirely how the viewer handles these -- but I'll figure it out. In any case, I see: http://slurl.com/secondlife/Foo/126/32/ secondlife://Foo/126/32/ (this doesn't come underlined on my viewer, for some reason) rezzme://ucigrid04.nacs.uci.edu:9003/Foo/126/32 (this also doesn't come underlined) Obviously, the closest to what we need is the rezzme handler. Is that working already? Should I take that on for the hypergrid? Or something else? Does anyone know if/how the viewer sends that hyperlink clicking event to the server? Crista _______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev _______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev _______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
