[Opensim-dev] OpenSim Comms

[Melanie]

Hi,

yes, a null module can then be provided to eliminate the ugliness of 
all those checks.

Melanie



Diva Canto wrote:
> Melanie wrote:
>> Hi,
>>
>> why should comms not be null? The point of optionality is to be 
>> optional. Comms may not be needed. Any or all types of comms may not 
>> be needed or wanted in a given application. So, comms should indeed 
>> be able to be null and a region module is the perfect place for it.
>>   
> 
> The ability to being null will require the profileration of conditionals 
> like this:
> 
> if (m_interregionComms != null)
>    m_interregionComms.SendChildAgentUpdate(...)
> 
> which is ugly and error-prone.
> 
> What we want is to have components that implement the Comms interfaces 
> in a empty manner. So the EmptyInterregionComms would be
> 
> class EmptyInterregionComms : IRegionModule, IInterregionComms
> {
>     public bool SendChildAgentUpdate(...) { return true; }
> }
> 
> 
> 
>> Also, the modules should really not chain. Where they do, that 
>> should be configurable and optional.
>>
>> Melanie
>>
>>
>> Diva Canto wrote:
>>   
>>> MW wrote:
>>>     
>>>> I think we should use REST for most of the comms, but am a little bit 
>>>> wary about if it will be the right choice for some of the region to 
>>>> region comms. And if the overhead in lots of http requests/posts will 
>>>> be too much, for messages like ChildAgentUpdate that we should be 
>>>> sending quite often.
>>>>       
>>> I have the same reservations as you on the particular case of 
>>> ChildAgentUpdate. However, assuming the HTTP server is up to the task, 
>>> sending over HTTP is an improvement over sending over Remoting, I think. 
>>> Both are TCP-based, and Remoting has the additional overhead of using 
>>> reflection for serialization/deserialization, which is not the case for 
>>> the HTTP calls.
>>> But we'll find out if this is an overhead or not when this is deployed.
>>>
>>>     
>>>> As for making comms a Region module, I'm +1 to that sort of idea. In 
>>>> the past I have from time to time, gone through removing direct 
>>>> references from scene, and region modules to the comms manager and 
>>>> instead routing them through wrapper functions in 
>>>> SceneCommunicationService. So that at some point we could refactor it 
>>>> to remove the current comms manager and make SceneCommunicationService 
>>>> into some sort of region module.
>>>>
>>>> I know that recently we have started taking the reverse course and 
>>>> removing the wrapper function. Which also has its benefits as there 
>>>> isn't much point in having the wrapper if we keep the comms manager as 
>>>> it is.
>>>>
>>>>
>>>> But anyway to answer your questions, if you have a REST 
>>>> childagentUpdate working and its a improvement on what we have, then 
>>>> I'd say that there shouldn't be any problem with replacing the old 
>>>> method as the way to get it in the quickest.
>>>>
>>>> But I think we really should have some better method to do comms 
>>>> plugin replacement/configuration in the future, weather that is by 
>>>> having it as a region module, or just improving the current system. So 
>>>> if you want to do that now, then I think that would be great.
>>>>       
>>> Right now, I'm following Melanie's advice and implement this as region 
>>> modules. Like this:
>>>
>>> OpenSim/Region/Environment/Modules/Local
>>> OpenSim/Region/Environment/Modules/REST
>>>
>>> Then in OpenSim.ini we'll have
>>>
>>> [Communications]
>>>
>>> ;InterregionComms = "LocalComms"
>>> ;InterregionComms = "RESTComms"
>>>
>>> (RESTComms is implemented using LocalComms too)
>>>
>>> This will help making the transition incremental without disturbing what 
>>> already exists, and slowly making the existing Comms code dead.
>>>
>>> I don't think this architecture is exactly right, for a number of 
>>> reasons. Communications pertains to Regions, yes, but not to 
>>> Region/Environment. And communications may be empty but should never be 
>>> null, so the region module concept is not the best; it will be better to 
>>> have interfaces and replaceable DLLs. Essentially, I think the current 
>>> design OpenSim.Region.Communications.* is the right one, but needs some 
>>> improvements. Probably we should have something like this:
>>>
>>> OpenSim/Region/Communications/Interregion/Local
>>> OpenSim/Region/Communications/Interregion/REST
>>> OpenSim/Region/Communications/Interregion/<others>
>>> OpenSim/Region/Communications/UserService/Local
>>> OpenSim/Region/Communications/UserService/REST
>>> ...
>>>
>>> And then
>>>
>>> [Communications]
>>>
>>> ;InterregionComms = 
>>> "OpenSim.Region.Communications.Interregion.LocalComms.dll"
>>> ;InterregionComms = 
>>> "OpenSim.Region.Communications.Interregion.RESTComms.dll"
>>> ;UserServiceComms = 
>>> "OpenSim.Region.Communications.UserService.LocalComms.dll"
>>> ...
>>>
>>> But for now, I'm going with region modules, just to make it work without 
>>> interfering with the existing Comms, and to study the best manner of 
>>> componentizing this whole thing.
>>>
>>> _______________________________________________
>>> 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