d...@metaverseink.com wrote:
> 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.
If bundling is the only reasonable way forward than fair enough. Perhaps
looking at some code might help. For
instance, in HGUserServices in OpenSim.Region.Communications.Hypergrid.dll,
there's a lot of the following
public override List<AvatarPickerAvatar>
GenerateAgentPickerRequestResponse(UUID queryID, string query)
{
if (m_localUserServices != null)
return
m_localUserServices.GenerateAgentPickerRequestResponse(queryID, query);
return base.GenerateAgentPickerRequestResponse(queryID, query);
}
Here, I can imagine a way in which this stuff could be restructured so that
HGUserServices relies on LocalUserServices
in a plugin fashion where HG and Local don't need to be aware of each other.
But then there are other methods in this class such as
public override void LogOffUser(UUID userid, UUID regionid, ulong
regionhandle, Vector3 position, Vector3 lookat)
{
string url = string.Empty;
if ((m_localUserServices != null) && !IsForeignUser(userid, out
url))
m_localUserServices.LogOffUser(userid, regionid, regionhandle,
position, lookat);
else
base.LogOffUser(userid, regionid, regionhandle, position,
lookat);
}
where some awareness of whether a user is local or foreign - IsForeignUser() -
appears to be required by HG. If there's
no way to make this check more generic then that would appear to lead towards a
higher level of coupling which may make
it a lot easier to put everything in monolithic dlls/big modules.
I looked at this because I was thinking of actually doing this with the limited
pre-existing internal module system in
UserManagerBase which makes it possible to source user 'data' from multiple
internal plugins. But the presence of
methods such as LogOffUser() raised the difficulty bar too high for my brain
time budget at that time.
>
>> 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.
Hmm, having configuration variables to switch Hypergrid between 'standalone'
and 'LLGrid' sounds subtly worse if
anything. But I do think there's a trade off here between complexity in the
configuration files and usability. Perhaps
this could be alleviated by a further config section that most users wouldn't
have to look at that defines the plugins
that 'Sandbox', 'LLGrid' and 'Hypergrid' actually use. Then a 3rd party could
define their own label to put in
ServiceConnectors. But this might be hopeless naive since it's off the top of
my head.
If I were you, I would follow the path of least resistance unless it made
things horribly messy internally (perhaps this
is the point).
Also, I'd rather see that we leave 'LL' out of this if only because they could
change their model in the future for all
we know :).
--
justincc
Justin Clark-Casey
http://justincc.wordpress.com
_______________________________________________
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
