<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
<meta http-equiv="Content-Type" content="text/html; charset=unicode">
<meta name="Generator" content="Microsoft SafeHTML">
<style>
.hmmessage P
{margin:0px;padding:0px;}
body.hmmessage
{font-size:10pt;font-family:Verdana;}
</style>
<style>
.hmmessage P
{margin:0px;padding:0px;}
body.hmmessage
{font-size:10pt;font-family:Verdana;}
</style>
<br>> > 2. On your previous suggested ini stuff, in my opinion something like<br>> > <br>> > UserService = { local | remote }<br>> > <br>> > would be clearer than<br>> > <br>> > LocalUserService = {True|False}<br>> > <br>> > From what I remember, specifying remote is understandable even if the services are actually on the same machine (but <br>> > one has chosen to run them as separate processes). Local would naturally denote the use of services in the same process <br>> > as the simulator.<br>> <br>> Actually, there's a subtle but very important difference in the case of <br>> hypergrid. A standalone grid wanting to allow Guests would have to use <br>> the Remote dll, even though the service for local users is local.<br><br>I don't see a problem with 'chaining' services; something like<br><br>[RegionResourceServices]<br>
GridService = OpenSim.Region.Communications.Hypergrid.dll, HGGridServices<br><br>[Hypergrid]<br>RemoteGridService = OpenSim.Region.Communications.OGS1.dll, OGS1GridServices <br><br>> This is, in fact, the kernel of the complexity here. Local has been <br>> designed to be Sandbox connectors, and OSG1 has been designed to connect <br>> with exactly *one* of each type of service. All remote calls in it <br>> hardcode serversInfo.xxxURL.<br><br>Yes. As part of the login/distributed assets refactoring, I was thinking of introducing an UserServicesManager that would keep proxies to all registered user services. Of course, I never got that far.<br><br>> The Hypergrid needs the regions to interact with *several* of each type <br>> of service, potentially, including the local one. So, most of the <br>> hypergrid changes have to do with determining local vs remote and, if <br>> remote, determining the service URL, making it a variable instead of a <br>> constant.<br><br>Again, some kind of repository for proxy classes would probably be the easy way, I think. the proxy classes could just as well be non-proxy persistent (local db), non-proxy volatile (in-mem), proxy to 'home' user service or proxy to foreign service. It would be the proxies that contained the protocol-specific functions to resolve calls (or just local in-mem calls in case of local)<br><br>+1 on the<br><br>> AllowGuests = {True|False}<br>vs<br>> gridmode = {True|False}<br><br><br>> So if we want to keep 3 architectures around, as separate architectures <br>> (and not one, more general), we have a meta option here:<br>> <br>> ServiceConnectors = {Sandbox|LLGrid|Hypergrid}<br><br>again, I guess service connector plugins could report a 'short name' that could be used in resolving configurations like this.<br> <br>> With this, I can make the hypergrid architecture have configuration <br>> variables to be able to generate all of the behaviors of Sandbox and <br>> LLGrid, and more -- basically place the ideas on my original email under <br>> the Hypergrid mode, and leave the other two as they are now.<br><br>For what it's worth, I think that all the various services should share a common abstract baseclass (per domain) so we can pull up and push down freely.<br><br>/Stefan<br><br></body>
</html>