> > 2. On your previous suggested ini stuff, in my opinion something like
> >
> > UserService = { local | remote }
> >
> > would be clearer than
> >
> > LocalUserService = {True|False}
> >
> > From what I remember, specifying remote is understandable even if the
> > services are actually on the same machine (but
> > one has chosen to run them as separate processes). Local would naturally
> > denote the use of services in the same process
> > as the simulator.
>
> Actually, there's a subtle but very important difference in the case of
> hypergrid. A standalone grid wanting to allow Guests would have to use
> the Remote dll, even though the service for local users is local.
I don't see a problem with 'chaining' services; something like
[RegionResourceServices]
GridService = OpenSim.Region.Communications.Hypergrid.dll, HGGridServices
[Hypergrid]
RemoteGridService = OpenSim.Region.Communications.OGS1.dll, OGS1GridServices
> This is, in fact, the kernel of the complexity here. Local has been
> designed to be Sandbox connectors, and OSG1 has been designed to connect
> with exactly *one* of each type of service. All remote calls in it
> hardcode serversInfo.xxxURL.
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.
> The Hypergrid needs the regions to interact with *several* of each type
> of service, potentially, including the local one. So, most of the
> hypergrid changes have to do with determining local vs remote and, if
> remote, determining the service URL, making it a variable instead of a
> constant.
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)
+1 on the
> AllowGuests = {True|False}
vs
> gridmode = {True|False}
> So if we want to keep 3 architectures around, as separate architectures
> (and not one, more general), we have a meta option here:
>
> ServiceConnectors = {Sandbox|LLGrid|Hypergrid}
again, I guess service connector plugins could report a 'short name' that could
be used in resolving configurations like this.
> With this, I can make the hypergrid architecture have configuration
> variables to be able to generate all of the behaviors of Sandbox and
> LLGrid, and more -- basically place the ideas on my original email under
> the Hypergrid mode, and leave the other two as they are now.
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.
/Stefan
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
