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

[Charles Krinke]

I would urge us to make changes to the master avatar stuff with notice and encouragement of folks to write FAQ, wiki entries, mini-apnotes and anything else that will help cut down on confusion of those who have significant effort invested into builds on existing regions.

Charles




________________________________
From: Melanie <melanie at t-data.com>
To: diva at metaverseink.com; opensim-dev at lists.berlios.de
Sent: Wednesday, April 29, 2009 1:52:47 PM
Subject: Re: [Opensim-dev] moving away from grid vs. standalone

I have done a lot of stuff related to that. Master avatar should not 
even exist in the way it still does today, that is legacy. The very 
same thing can be done in another way (code-wise).
So the existing master avatar stuff can be removed,if that is the 
only blocker, i'll think up some new semantics for that and 
implement it.

Melanie

diva at metaverseink.com wrote:
> 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
>>>
>>>
>> 
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20090429/9b5abdfc/attachment-0001.html>