[Opensim-dev] OpenSim Comms

[Melanie]

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.

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