[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