[Opensim-dev] moving away from grid vs. standalone

[diva at metaverseink.com]

Justin Clark-Casey wrote:
> I like this generally but I do have the following comments.
> 
> 1.  I'm not a huge fan of this since, like Stefan, I'd ideally like it to be possible to package an OpenSim that 
> supports only a single architecture, with no trace of other architecture code in there at all.  Putting everything into 
> one dll makes this impossible, though perhaps it's not really that big a deal.  Is it really not possibly to do this via 
> plugins (where the hg code relies on the presence of local service plugins?).

OK. It might be possible to merge the hypergrid-related conditionals in 
the connectors of what's currently known as OGS1. If that's possible, 
then we'd have two dlls:

OpenSim.Region.ResourceServicesConnectors.Local.dll
OpenSim.Region.ResourceServicesConnectors.Remote.dll

Where "Remote" means calls to local and remote services out there, and 
not just to the ones associated with the grid; so includes calls to, for 
example, user services of foreign users -- if the sim is configured to 
deal with them.

We already have the dependency OGS1 depends-on Local, that would 
continue to be, that is, Remote depends-on Local. So the fact that a sim 
uses the Remote dll doesn't mean that all calls to services are remote 
calls; some may be local.

> 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.

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.

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.

The question is: do you want to hold on the the 'old' grid model, 
*architecturally speaking*? (not behaviorally) Or do you want to 
generalize the architecture, and then let people configure its 
*behavior* with things like

AllowGuests = {True|False}

?

I have a preference for the generalization, but I'm not strongly 
pushing, I can go both ways.
The thing that *really* needs to go is this

gridmode = {True|False}

This is an absolute show stopper; it binds us down to two monolithic things.

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}

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.