<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<style>
<!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
{font-family:Verdana;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:inherit;
panose-1:0 0 0 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page Section1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.Section1
{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=EN-AU link=blue vlink=purple>
<div class=Section1>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Do we need the comms manager?<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Can’t we just register them individually via Scene.RegisterModuleInterface,
then pull what we want when we need it?<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Adam<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<div style='border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt'>
<div>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'>
<p class=MsoNormal><b><span lang=EN-US style='font-size:10.0pt;font-family:
"Tahoma","sans-serif"'>From:</span></b><span lang=EN-US style='font-size:10.0pt;
font-family:"Tahoma","sans-serif"'> opensim-dev-bounces@lists.berlios.de
[mailto:opensim-dev-bounces@lists.berlios.de] <b>On Behalf Of </b>Stefan
Andersson<br>
<b>Sent:</b> Thursday, 26 February 2009 2:10 AM<br>
<b>To:</b> Michael Wright; opensim-dev@lists.berlios.de<br>
<b>Subject:</b> Re: [Opensim-dev] Comms Manager<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif"'>Actually,
I think the various 'module types' should bee seen as reflecting
on what system resources will be made available to those modules - both as
a conveniense (better suited API entrypoints) and for security (being able
to set policies on modules)<br>
<br>
Also, I very much see these repository functions that we are looking at as
taking care of 'configuration' - ie, to make sure that the module code don't
have to take care of, or know anyhting about, the configuration of other parts
of the system.<br>
<br>
Best regards,<br>
Stefan Andersson<br>
Tribal Media AB<br>
<br>
<br>
<br>
<o:p></o:p></span></p>
<div class=MsoNormal align=center style='text-align:center'><span
style='font-size:10.0pt;font-family:"Verdana","sans-serif"'>
<hr size=2 width="100%" align=center id=stopSpelling>
</span></div>
<p class=MsoNormal style='margin-bottom:12.0pt'><span style='font-size:10.0pt;
font-family:"Verdana","sans-serif"'>Date: Thu, 26 Feb 2009 10:05:46 +0000<br>
From: michaelwri22@yahoo.co.uk<br>
To: opensim-dev@lists.berlios.de<br>
Subject: Re: [Opensim-dev] Comms Manager<o:p></o:p></span></p>
<table class=MsoNormalTable border=0 cellspacing=0 cellpadding=0>
<tr>
<td valign=top style='padding:0cm 0cm 0cm 0cm'>
<p class=MsoNormal>PS. One issue that I don't like about a lot of the
Region to UGAIM code that is currently in some of the region modules, is how
the network/transport code is mixed up with the handling of some basic
features like friends, presences etc. I do think we should have separate
transport modules.<br>
<br>
So maybe a IPresenceTransportService, then we could have PresenceOGS1Module
that implements that. And the PresenceModule uses that interface for talking
to and from the UGAIM servers. Rather than network code being mixed in with
logic code in a single module.<br>
<br>
Now if these are region modules or Global/comms modules is a different
question. I just think we should have more specialisation in the modules so
we can easily change the network protocols without replacing the whole sub system
of a feature.<br>
<br>
--- On <b>Thu, 26/2/09, MW <i><michaelwri22@yahoo.co.uk></i></b> wrote:<o:p></o:p></p>
<p class=MsoNormal style='margin-bottom:12.0pt'>From: MW
<michaelwri22@yahoo.co.uk><br>
Subject: Re: [Opensim-dev] Comms Manager<br>
To: opensim-dev@lists.berlios.de<br>
Date: Thursday, 26 February, 2009, 9:44 AM<o:p></o:p></p>
<div id="EC_yiv1148541233">
<table class=MsoNormalTable border=0 cellspacing=0 cellpadding=0>
<tr>
<td valign=top style='padding:0cm 0cm 0cm 0cm'>
<p class=MsoNormal><span style='font-family:"inherit","serif"'>Well I agree
the name CommsManager is a bad choice and I'm all for changing/getting rid
of that. I don't see this as a Manager but just another registery of
modules. My proposal certainly isn't about making/keeping all the comms
code centralised. I totally agree that we should have modules, and break up
the current classes/interfaces in the Comms Manager.<br>
<br>
The main differences between my proposal for comms modules and region
modules are comms modules are initialised before regions/scenes are created
and have no direct references to the scenes (although of course
scene/region modules could register to events on them etc). But even that
no direct reference could be changed. <br>
<br>
Also having this separate module system would also allow it to use the
modules from the Grid,User and messaging servers (and maybe later the
inventory/asset servers), which I think could help a lot to cut down the
duplications we have between standalone and grid servers.<br>
<br>
But my main issue with this concept (the comms modules and registery) is
there isn't really that much difference between these and region modules.
So is there any point in having the two systems/registeries. My concept is
basically a Shared module and registery but more at the application level
rather than the region level. <br>
<br>
I'm not actually really against having all the comms in region modules. But
do think it brings up some issues. I don't actually agree that app level
code/plugins shouldn't be able to access the comms to the UGAIM servers
without going through regions or duplicating the comms handling code. And I
know some of the other devs have even more issues with all the comms code
being in region modules. So we need to find a solution that we are all
happy with.<br>
<br>
Maybe the solution is to work on separating the shared region modules out,
so they are a actual different class/interface to the normal region modules
and maybe a different registery(?). As has been talked about in irc a lot
recently. But I guess these would still be accessed through regions/scenes?
So really no different from a usage point of view to what we have now.<br>
<br>
<br>
--- On <b>Thu, 26/2/09, Melanie <i><melanie@t-data.com></i></b>
wrote:<o:p></o:p></span></p>
<p class=MsoNormal style='margin-bottom:12.0pt'><span style='font-family:
"inherit","serif"'>From: Melanie <melanie@t-data.com><br>
Subject: Re: [Opensim-dev] Comms Manager<br>
To: michaelwri22@yahoo.co.uk, opensim-dev@lists.berlios.de<br>
Date: Thursday, 26 February, 2009, 4:33 AM<o:p></o:p></span></p>
<pre>Hi,<br>
<br>
I'm against a CommsManager class, on the grounds I'm against most <br>
other *Manager classes.<br>
They serve as holders for stuff that seems straightforward <br>
initially, but soon become monolithic molochs that make a simple <br>
change, like adding<o:p></o:p></pre><pre> a<br>
single method on a single interface, a task of <br>
changing 37 files.<br>
<br>
I don't think that any of the region comms currently in region <br>
modules will need to be accessed from application plugins, since <br>
they are region specific.<br>
<br>
I would envision a system of application plugins similar to region <br>
plugins, that would expose their own comms interfaces to do the sort <br>
of comms the application, rather than a region, needs to do.<br>
<br>
Forcing region comms to go through some CommsManager seems wrong.<br>
<br>
Here, I see that specialization is about to be discarded for <br>
convenience, and I don't agree. Region comms, like teleport comms, <br>
don't belong in an application level comms broker, they belong in <br>
region modules. So do most other comms I'm aware of. Take users, fir <br>
instance. The application never talks about users, regions do. The <br>
user server comms really should be a shared region module. <br>
Modularisation is<o:p></o:p></pre><pre> the<br>
key here, not centralisation.<br>
<br>
Melanie<br>
<br>
<br>
MW wrote:<br>
> More and more of the Region to UGAIM comms and Region to Region comms, is<br>
being moved out of the Comms Manager and into region modules. Is this a process<br>
we should continue and move everything out of there and into Region modules? <br>
> <br>
> I'm a bit torn on that issue, and I think a few other people are too.<br>
We all know the current comms manager system is not the best :) And its a real<br>
pain to customise. <br>
> <br>
> One issue with having it all in region modules, is that everything has to<br>
go through regions to be able to use those interfaces. Making it harder for app<br>
plugins to do any comms related work. <br>
> <br>
> So if we decide to stick with a separate comms system (rather than moving<br>
it to region modules), how can we improve it?<br>
> <br>
> I think the first two tasks are:<br>
> * to improve the interfaces/make it<o:p></o:p></pre><pre> easier to<br>
extend.<br>
> * and to make it so its loaded from plugins/dlls. <br>
> <br>
> One simple way of allowing plugins to create and setup the Comms Manager<br>
would be making some small changes to the IApplicationPlugin interface:<br>
> <br>
> * Add a PostInitialise method to that interface. <br>
> * Then changing the LoadRegionsPlugin so that it created the regions in<br>
the IApplicationPlugin.PostInitialise call. <br>
> * Which would allow us to create some SetupCommsManagerPlugins which could<br>
do its work in the IApplicationPlugin.Initialise() call.<br>
> <br>
> [Note that brings up another issue that I want to deal with in another<br>
email soon... of how do we define which plugins are loaded. And also if there<br>
are multiple plugins, of the same type, in a single dll, how do we make some of<br>
them get loaded but not others?]<br>
> <br>
> The next task would be to improve the interfaces of the Comms Manager<o:p></o:p></pre><pre> and<br>
allow it to be<br>
expanded easier.<br>
> <br>
> The current set of interfaces in the Comms manager are:<br>
> <br>
> public class CommunicationsManager<br>
> {<br>
> public IUserService UserService<br>
> public IMessagingService MessageService;<br>
> public IGridServices GridService<br>
> public UserProfileCacheService UserProfileCacheService<br>
> public IAvatarService AvatarService<br>
> public IAssetCache AssetCache<br>
> public NetworkServersInfo NetworkServersInfo <br>
> public IUserAdminService UserAdminService' <br>
> public BaseHttpServer HttpServer;<br>
> }<br>
> <br>
> I propose making it so the CommsManager also implements the<br>
IGridServiceCore interface which I've added to the User/Grid/Messaging<br>
servers, as part of the process of modulising them.<br>
> <br>
> public interface IGridServiceCore<br>
> {<br>
> <o:p></o:p></pre><pre> T<br>
Get<T>();<br>
> void RegisterInterface<T>(T iface);<br>
> bool TryGet<T>(out T iface);<br>
> BaseHttpServer GetHttpServer();<br>
> }<br>
> <br>
> Then the components of the CommsManager can register themselves with that,<br>
and request other interfaces/Components. At the moment it would still need the<br>
old interfaces to be assigned, as external code use them. But over time, we<br>
should then change the external code so they use the TryGet<T>(out T<br>
iface) call when they want one of the interfaces/Components. <br>
> <br>
> So eventually the CommsManager will basically just be that interface and a<br>
set of "modules" loaded and registered with it. <br>
> <br>
> This brings the CommsManager more in line with the Region module system<br>
and the IClientCore and soon to be in use UGM servers system. We could even make<br>
it so it could load the same modules as the UGM servers<o:p></o:p></pre><pre> use if we<br>
wanted to. <br>
> <br>
> So thoughts, comments, bad fruit being thrown wanted.<br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> ------------------------------------------------------------------------<br>
> <br>
> _______________________________________________<br>
> Opensim-dev mailing list<br>
> Opensim-dev@lists.berlios.de<br>
> https://lists.berlios.de/mailman/listinfo/opensim-dev<br>
_______________________________________________<br>
Opensim-dev mailing list<br>
Opensim-dev@lists.berlios.de<br>
https://lists.berlios.de/mailman/listinfo/opensim-dev<o:p></o:p></pre></td>
</tr>
</table>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<pre>_______________________________________________<br>
Opensim-dev mailing list<br>
Opensim-dev@lists.berlios.de<br>
https://lists.berlios.de/mailman/listinfo/opensim-dev<o:p></o:p></pre></td>
</tr>
</table>
<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Verdana","sans-serif"'><o:p> </o:p></span></p>
</div>
</div>
</body>
</html>