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

[Justin Clark-Casey]

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?

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

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.

3.  As Dahlia has already commented and you've acknowledged, it seems it would be best if the default configuration 
remained all local services [nee standalone].

4.  If you make these changes, please could you also change the wiki configuration docs.

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


-- 
justincc
Justin Clark-Casey
http://justincc.wordpress.com