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

[diva at metaverseink.com]

I think that there is a technical obstacle to doing that: the master 
avatar stuff, that happens early on in the application (OpenSimBase, 
line 688), needs to have the communication code in place. I think -- 
although I may be wrong -- that that happens before region modules are 
in place.

Melanie wrote:
> I still think all that stuff can be put in region modules....
> 
> Melanie
> 
> diva at metaverseink.com wrote:
>> Maybe the right name for it is
>> OpenSim.Region.ResourceServicesConnectors.dll
>>
>> diva at metaverseink.com wrote:
>>> Stefan Andersson wrote:
>>>> How about
>>>>  
>>>> ---
>>>> [RegionResourceServices]
>>>> ;GridService = OpenSim.Region.Communications.Hypergrid.dll, 
>>>> HGGridServices
>>>> ;GridService = OpenSim.Region.Communications.Local.dll, 
>>>> LocalBackEndServices
>>>>  
>>>> GridService = OpenSim.Region.Communications.OGS1.dll, OGS1GridServices
>>>>  
>>>> [GridService]
>>>> grid_server_url = "http://192.168.1.101:9000"
>>>> grid_send_key = "null"
>>>> grid_recv_key = "null"
>>>
>>> The problem with specifying dlls *in this particular case* is that 
>>> these things aren't entirely orthogonal/different. The Hypergrid dlls 
>>> are a mashup of the other two. Therefore from a source code 
>>> perspective it makes things a heck of a lot more complicated than 
>>> they need to be if we simply merge things and use conditionals on 
>>> configuration variables. For example, hyperlinks (part of grid 
>>> services) is a really simple extension to LocalGrid services.
>>>
>>> The issue of local vs remote services isn't entirely orthogonal 
>>> either. Some parts of OGS1 use Local services -- the well know 
>>> pattern of trying things locally first and if that doesn't work, 
>>> proceed for a remote service call (e.g. OGS1 grid services does that).
>>>
>>> I see why you want this, in abstract. If another service comes along, 
>>> it can simply be added as a component. Or if someone writes, say, a 
>>> completely different inventory service, its interface can be added as 
>>> dll.
>>>
>>> But in this particular case, for the code we already have, I think 
>>> that having Local.dll, OGS1.dll and Hypergrid.dll is not working 
>>> well, even if the configuration process is the one you suggest. The 
>>> code is mess; things are _way_ more complicated than they need to be.
>>>
>>> So, maybe, what we can do is merging these two ideas. We'll have only 
>>> one dll (OpenSim.Region.ResourceServices.dll), but we'll specify 
>>> things in OpenSim.ini the way that you suggest, so that if anyone 
>>> comes along and wants to plug in a different inventory service, he 
>>> can just specify the  other dll and an entry class name for it.
>>>
>>> What do you think?
>>>
>>>
>>>> [Security]
>>>>  
>>>> SessionAuthentication = {True|False}
>>>> KeyAuthentication = {True|False}
>>>>
>>>> ---
>>>>  
>>>> The constructor is being fed a config source, so the service can 
>>>> pick out whatever it needs.
>>>>  
>>>> All the shipped grid services could move into one assembly, as we're 
>>>> explicitly specifying the implementing calss.
>>>>  
>>>> I believe this approach would get us improved flexibility.
>>>>
>>>> /Stefan
>>> _______________________________________________
>>> Opensim-dev mailing list
>>> Opensim-dev at lists.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>>
>