<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Melanie wrote:
<blockquote cite="mid:49590AB4.1080808@t-data.com" type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<br>
The ability to being null will require the profileration of
conditionals like this:<br>
<br>
if (m_interregionComms != null)<br>
m_interregionComms.SendChildAgentUpdate(...)<br>
<br>
which is ugly and error-prone.<br>
<br>
What we want is to have components that implement the Comms interfaces
in a empty manner. So the EmptyInterregionComms would be<br>
<br>
class EmptyInterregionComms : IRegionModule, IInterregionComms<br>
{<br>
public bool SendChildAgentUpdate(...) { return true; }<br>
}<br>
<br>
<br>
<br>
<blockquote cite="mid:49590AB4.1080808@t-data.com" type="cite">
<pre wrap="">
Also, the modules should really not chain. Where they do, that
should be configurable and optional.
Melanie
Diva Canto wrote:
</pre>
<blockquote type="cite">
<pre wrap="">MW wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">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.
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">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
<a class="moz-txt-link-abbreviated" href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a>
<a class="moz-txt-link-freetext" href="https://lists.berlios.de/mailman/listinfo/opensim-dev">https://lists.berlios.de/mailman/listinfo/opensim-dev</a>
</pre>
</blockquote>
<pre wrap=""><!---->_______________________________________________
Opensim-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a>
<a class="moz-txt-link-freetext" href="https://lists.berlios.de/mailman/listinfo/opensim-dev">https://lists.berlios.de/mailman/listinfo/opensim-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>