[Opensim-dev] OpenSim Comms

Diva Canto diva at metaverseink.com
Mon Dec 29 17:45:31 UTC 2008


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20081229/c3011adc/attachment-0001.html>


More information about the Opensim-dev mailing list