<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>Dalien (and others)<BR>
<BR>
the 'hybrid backend service' you are talking about sounds very much like the 'Service/Manager' pattern I have been advocatong for quite some while now;<BR>
<BR>
just for a laugh, I've implemented so that the OGS Grid comms now have a Local Grid comm, and forwards all requests to it to see if it can be handled locally, if not, it accesses the grid.<BR>
<BR>
The latter has a 'RegionInfo' cache, and a 'RegionListener' cache (which is the remoting endpoints for the regions within the instance)<BR>
<BR>
I think we can get this really nice with a bit of love and quite some patience.<BR>
<BR>
/Stefan<BR>
<BR> <BR>
<BLOCKQUOTE>
<HR id=EC_stopSpelling>
Date: Tue, 25 Sep 2007 03:36:59 +0200<BR>From: dalienta@gmail.com<BR>To: opensim-dev@lists.berlios.de<BR>Subject: [Opensim-dev] "Friendly teleports" between the standalone sims<BR><BR>Folks, <BR><BR>wanted to check your opinion on this.<BR><BR>I've slowly started hacking up the code to try out my idea of "friendly teleports".<BR><BR>The way I am playing with it is by making the "hybrid backend services" - a backend services class has the LocalBackEndServices as a class member, first redirects all of the calls to it, and then handles the "failure" cases in InformRegionOfChildAgent, ExpectAvatarCrossing, AcknowledgeAgentCrossed, RequestNeighbourInfo. <BR><BR>The latter retrieves the regioninfo from the "remote regions cache" - hash indexed by the regionid, which would need to be populated within the flow of the said os* function.<BR><BR>The rationale for making the "overlay class" is to avoid the duplication of the functionality of "same-server" functions which are there already in the local backend services - and have just the "intergrid" functions using the remoting which I snarf from the OGS1 backend services code. <BR><BR>Since the regionhandle seems to be quite tied to the grid coordinates, I am thinking of the following scheme:<BR><BR>1) I add a new os* function, which would take the URL of the sim + the coordinates as the parameter. (could be a PATH_INFO-like scheme, i.e.: <A href="http://sim-domain-name/path_to_handler_or_sim_name_in_case_of_grid/x/y/z" target=_blank>http://sim-domain-name/path_to_handler_or_sim_name_in_case_of_grid/x/y/z</A><BR><BR>2) when the user script calls this function, the source sim A retrieves the info about the destination sim (grid) B via this URL (the mainly interesting stuff for the current implementation is the remoting IP/port) - but might change in the future. This is the point where the user might get a dialog box "do you want to teleport to ..." <BR><BR>3) A and B need to negotiate a "temporary" regionHandle, which would be unused in both sims (grids). <BR><BR>3a) A sends a request with the proposed region handle to sim B<BR>3b) if this regionhandle is ok - then B responds to it, else it responds with "NAK", and proposes its own region handle. <BR>3c) A does the same - if still not ok, selects the new temp region handle and the story repeats. If after N attempts we do not succeed, the teleport is declared as failed. If it succeeds, then both A and B have in the cache the info about the temporary handle. <BR><BR>4) the user is sent to the target sim B using the scene.RequestTeleportLocation()<BR><BR>5) once the user arrives, the sim (grid) B initiates a second teleport to the "real" region and signals back to sim (grid) A that the temporary location there can be cleared. <BR><BR>once the teleport succeeds, the sim(grid) B clears the temporary location as well. The temporary locations would be probably cutting off the chunk of the topmost X/Y coordinates.<BR><BR>This is a raw idea, I still need to test it further, but I think it might work.. <BR><BR>/d<BR><BR>p.s. I do not open yet the can of worms with the inventory, etc. :)<BR><BR></BLOCKQUOTE></body>
</html>