And, as an afterthought:
IClientTrackerModule
{
OnNewClient(IScene scene, IClientCore client);
OnClientClose(IScene scene, IClientCore client);
}
IClientTracker : IGlobalModule, IClientTrackerModule
Initialise()
{
OnNewScene += OnNewScene;
OnRemoveScene += OnRemoveScene;
}
OnNewScene(IScene scene)
{
scene.RegisterModuleInterface<IClientTrackerModule>(this);
}
OnRemoveScene(Iscene scene) // Remove all this scene's clients
{
}
OnNewClient(IScene scene, IClientCore client)
{
}
OnClientClose(IScene scene, IClientCore client)
{
}
.....
So, if you really want it, you can have it.
Melanie
Melanie wrote:
> You just can't let go of the centralistic *Manager idea..!
>
> IMHO, clients have no business at app level. Clients connect to
> regions through client stacks. Which can be shared modules for
> constellations where one client connection handles all regions in an
> instance.
>
> IGlobalModuleRegistry
> {
> Initialise();
> RegisterModuleInterface<T>(T instance);
> RequestModuleInterface<T>();
>
> // Triggered whan a Scene is loaded
> OnNewScene(IScene);
> InRemoveScene(IScene);
> }
>
> IScenesTrackerModule : IGlobalModule
> {
> Initialise();
> List<IScene> Scenes { get; }
> IScene FindSceneByName(string name);
> IScene FindSceneByUUID(UUID sceneID);
> .....
> }
>
> See? That scenes module is actually loaded and registers as a
> perfectly normal module inthe module registry.
> It builds and maintains a scene list automatically by means of the
> OnNewScene and OnRemoveScene events!
>
> Easy. No mess with contained classes and having to edit the
> container all the time.
>
> I hate:
>
> SomethingClass
> {
> IWhatever whatever;
> ISoWhat sowhat;
> }
>
> It cements a structure that could be inappropriate a month from now.
>
> Melanie
>
> Melanie
>
> Frisby, Adam wrote:
>> My thoughts:
>>
>> IGlobalModule {
>> Initialise(ModuleManager x)
>> Start()
>> Stop()
>> }
>>
>> ModuleManager {
>> SceneManager,
>> ClientManager,
>> ModuleInterfaces<T>
>> }
>>
>> From: [email protected]
>> [mailto:[email protected]] On Behalf Of Stefan Andersson
>> Sent: Thursday, 26 February 2009 3:00 AM
>> To: [email protected]
>> Subject: Re: [Opensim-dev] Comms Manager
>>
>> ... did we not just come full circle?
>>
>> I believe were all in agreement here, just varying on what to call stuff and
>> exactly what stuff they should be connected to.
>>
>> I'm confident all that will sort itself out. I think we have established a
>> roadmap though.
>>
>> Best regards,
>> Stefan Andersson
>> Tribal Media AB
>>
>>
>>
>>
>>> Date: Thu, 26 Feb 2009 10:40:34 +0000
>>> From: [email protected]
>>> To: [email protected]
>>> Subject: Re: [Opensim-dev] Comms Manager
>>>
>>> What Adam said.
>>>
>>> That is precisely what I am thinking of, and what we all, in a bog
>>> discussion, already once agreed on, when Diva asked and we decided
>>> that interregion comms should be a module.
>>>
>>> I believe the comms needs of an application plugin are different
>>> from a region module's needs. I see no issue in haveinf _different_
>>> comms code in different places.
>>>
>>> I do agree that code duplication should be avoided.
>>>
>>> But I'm also taking a firm stand on CommsManager. CommsManager, as
>>> it is, needs tremendous effort to extend, and non-core code can not
>>> ever hook into it, because it has a fixed set of interfaces linked
>>> in. That is badness.
>>>
>>> So, I think I have a solution:
>>>
>>> Refactor all services currently in comms manager into region modules
>>> _or_ application plugins, depending on where it's used. Basically,
>>> everything that is only used by regions should be a region module.
>>>
>>> Rewrite comms manager as a registry of intefaces, that application
>>> plugins can register services with.
>>> This will be those comms manager services that are truly application
>>> level, means, are used by things other than regions, before regiosn
>>> are started, or in instances without regions.
>>>
>>> Now, each application module gets an event on creation of a scene
>>> anyway. So, thay can Scene.RegisterModuleInteferce<IWhatever>(this)
>>> with each new scene created, and offer their services to Scenes as well.
>>>
>>> If code was originally written as a region module, but is later
>>> found to be useful without regions (XMLRPC RemoteAdmin is one that
>>> comes to mind!), it can easily be moved to this interface and then
>>> publish itself to regions to provide region comms as well.
>>>
>>> In the case of RemoteAdmin, it's comms code (yes, a StreamHandler!)
>>> would be in an application plugin, exposing an IRemoteRegionAdmin to
>>> each region connected. A region module that does the region part of
>>> the work would grab that interface to access the underlying
>>> communications.
>>> That would also provide a very clean separation, as the application
>>> plugin can't execute anything on Scenes, because it has IScene only
>>> and doesn't ref Scene itself at all. Therefore it would be comms
>>> only, and the region module talking to it would be no comms at all.
>>> This seems logical because that way an instance with no active
>>> regions could still execute a create region command... that would be
>>> unavailable if no region was loaded at all!
>>> As Homer goes to refactor region loading and region modules, this
>>> will become more important.
>>>
>>> Again, I'm -1000 on having a monolithic component that requires core
>>> code edits to extend, but open to a solution as described above,
>>> which, IMHO, combines all that was said so far in a neat package.
>>>
>>> Melanie
>>>
>>>
>>> Stefan Andersson wrote:
>>> > I think that's what Melanie is leaning towards, but that would mean every
>>> > module would have to be connected to at least one scene.
>>> >
>>> >
>>> > I do believe that you would have modules doing stuff already from a
>>> > setting where there is no scenes loaded.
>>> >
>>> >
>>> >
>>> > The regionLoader, for example. :D
>>> >
>>> > Best regards,
>>> > Stefan Andersson
>>> > Tribal Media AB
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > From: [email protected]
>>> > To: [email protected]; [email protected]
>>> > Date: Thu, 26 Feb 2009 05:21:48 -0500
>>> > Subject: Re: [Opensim-dev] Comms Manager
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > Do we need the comms manager?
>>> >
>>> > Can't we just register them individually via
>>> > Scene.RegisterModuleInterface, then pull what we want when we need it?
>>> >
>>> > Adam
>>> >
>>> >
>>> >
>>> >
>>> > From: [email protected]
>>> > [mailto:[email protected]] On Behalf Of Stefan
>>> > Andersson
>>> > Sent: Thursday, 26 February 2009 2:10 AM
>>> > To: Michael Wright; [email protected]
>>> > Subject: Re: [Opensim-dev] Comms Manager
>>> >
>>> > 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)
>>> >
>>> > 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.
>>> >
>>> > Best regards,
>>> > Stefan Andersson
>>> > Tribal Media AB
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > Date: Thu, 26 Feb 2009 10:05:46 +0000
>>> > From: [email protected]
>>> > To: [email protected]
>>> > Subject: Re: [Opensim-dev] Comms Manager
>>> >
>>> >
>>> >
>>> >
>>> > 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.
>>> >
>>> > 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.
>>> >
>>> > 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.
>>> >
>>> > --- On Thu, 26/2/09, MW <[email protected]> wrote:
>>> > From: MW <[email protected]>
>>> > Subject: Re: [Opensim-dev] Comms Manager
>>> > To: [email protected]
>>> > Date: Thursday, 26 February, 2009, 9:44 AM
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > 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.
>>> >
>>> > 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.
>>> >
>>> > 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.
>>> >
>>> > 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.
>>> >
>>> > 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.
>>> >
>>> > 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.
>>> >
>>> >
>>> > --- On Thu, 26/2/09, Melanie <[email protected]> wrote:
>>> > From: Melanie <[email protected]>
>>> > Subject: Re: [Opensim-dev] Comms Manager
>>> > To: [email protected], [email protected]
>>> > Date: Thursday, 26 February, 2009, 4:33 AMHi,
>>> >
>>> >
>>> >
>>> > I'm against a CommsManager class, on the grounds I'm against most
>>> >
>>> > other *Manager classes.
>>> >
>>> > They serve as holders for stuff that seems straightforward
>>> >
>>> > initially, but soon become monolithic molochs that make a simple
>>> >
>>> > change, like adding a
>>> >
>>> > single method on a single interface, a task of
>>> >
>>> > changing 37 files.
>>> >
>>> >
>>> >
>>> > I don't think that any of the region comms currently in region
>>> >
>>> > modules will need to be accessed from application plugins, since
>>> >
>>> > they are region specific.
>>> >
>>> >
>>> >
>>> > I would envision a system of application plugins similar to region
>>> >
>>> > plugins, that would expose their own comms interfaces to do the sort
>>> >
>>> > of comms the application, rather than a region, needs to do.
>>> >
>>> >
>>> >
>>> > Forcing region comms to go through some CommsManager seems wrong.
>>> >
>>> >
>>> >
>>> > Here, I see that specialization is about to be discarded for
>>> >
>>> > convenience, and I don't agree. Region comms, like teleport comms,
>>> >
>>> > don't belong in an application level comms broker, they belong in
>>> >
>>> > region modules. So do most other comms I'm aware of. Take users, fir
>>> >
>>> > instance. The application never talks about users, regions do. The
>>> >
>>> > user server comms really should be a shared region module.
>>> >
>>> > Modularisation is the
>>> >
>>> > key here, not centralisation.
>>> >
>>> >
>>> >
>>> > Melanie
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > MW wrote:
>>> >
>>> >> More and more of the Region to UGAIM comms and Region to Region comms, is
>>> >
>>> > being moved out of the Comms Manager and into region modules. Is this a
>>> > process
>>> >
>>> > we should continue and move everything out of there and into Region
>>> > modules?
>>> >
>>> >>
>>> >
>>> >> I'm a bit torn on that issue, and I think a few other people are too.
>>> >
>>> > We all know the current comms manager system is not the best :) And its a
>>> > real
>>> >
>>> > pain to customise.
>>> >
>>> >>
>>> >
>>> >> One issue with having it all in region modules, is that everything has to
>>> >
>>> > go through regions to be able to use those interfaces. Making it harder
>>> > for app
>>> >
>>> > plugins to do any comms related work.
>>> >
>>> >>
>>> >
>>> >> So if we decide to stick with a separate comms system (rather than moving
>>> >
>>> > it to region modules), how can we improve it?
>>> >
>>> >>
>>> >
>>> >> I think the first two tasks are:
>>> >
>>> >> * to improve the interfaces/make it easier to
>>> >
>>> > extend.
>>> >
>>> >> * and to make it so its loaded from plugins/dlls.
>>> >
>>> >>
>>> >
>>> >> One simple way of allowing plugins to create and setup the Comms Manager
>>> >
>>> > would be making some small changes to the IApplicationPlugin interface:
>>> >
>>> >>
>>> >
>>> >> * Add a PostInitialise method to that interface.
>>> >
>>> >> * Then changing the LoadRegionsPlugin so that it created the regions in
>>> >
>>> > the IApplicationPlugin.PostInitialise call.
>>> >
>>> >> * Which would allow us to create some SetupCommsManagerPlugins which
>>> >> could
>>> >
>>> > do its work in the IApplicationPlugin.Initialise() call.
>>> >
>>> >>
>>> >
>>> >> [Note that brings up another issue that I want to deal with in another
>>> >
>>> > email soon... of how do we define which plugins are loaded. And also if
>>> > there
>>> >
>>> > are multiple plugins, of the same type, in a single dll, how do we make
>>> > some of
>>> >
>>> > them get loaded but not others?]
>>> >
>>> >>
>>> >
>>> >> The next task would be to improve the interfaces of the Comms Manager and
>>> >
>>> > allow it to be
>>> >
>>> > expanded easier.
>>> >
>>> >>
>>> >
>>> >> The current set of interfaces in the Comms manager are:
>>> >
>>> >>
>>> >
>>> >> public class CommunicationsManager
>>> >
>>> >> {
>>> >
>>> >> public IUserService UserService
>>> >
>>> >> public IMessagingService MessageService;
>>> >
>>> >> public IGridServices GridService
>>> >
>>> >> public UserProfileCacheService UserProfileCacheService
>>> >
>>> >> public IAvatarService AvatarService
>>> >
>>> >> public IAssetCache AssetCache
>>> >
>>> >> public NetworkServersInfo NetworkServersInfo
>>> >
>>> >> public IUserAdminService UserAdminService'
>>> >
>>> >> public BaseHttpServer HttpServer;
>>> >
>>> >> }
>>> >
>>> >>
>>> >
>>> >> I propose making it so the CommsManager also implements the
>>> >
>>> > IGridServiceCore interface which I've added to the User/Grid/Messaging
>>> >
>>> > servers, as part of the process of modulising them.
>>> >
>>> >>
>>> >
>>> >> public interface IGridServiceCore
>>> >
>>> >> {
>>> >
>>> >> T
>>> >
>>> > Get<T>();
>>> >
>>> >> void RegisterInterface<T>(T iface);
>>> >
>>> >> bool TryGet<T>(out T iface);
>>> >
>>> >> BaseHttpServer GetHttpServer();
>>> >
>>> >> }
>>> >
>>> >>
>>> >
>>> >> Then the components of the CommsManager can register themselves with
>>> >> that,
>>> >
>>> > and request other interfaces/Components. At the moment it would still
>>> > need the
>>> >
>>> > old interfaces to be assigned, as external code use them. But over time,
>>> > we
>>> >
>>> > should then change the external code so they use the TryGet<T>(out T
>>> >
>>> > iface) call when they want one of the interfaces/Components.
>>> >
>>> >>
>>> >
>>> >> So eventually the CommsManager will basically just be that interface and
>>> >> a
>>> >
>>> > set of "modules" loaded and registered with it.
>>> >
>>> >>
>>> >
>>> >> This brings the CommsManager more in line with the Region module system
>>> >
>>> > and the IClientCore and soon to be in use UGM servers system. We could
>>> > even make
>>> >
>>> > it so it could load the same modules as the UGM servers use if we
>>> >
>>> > wanted to.
>>> >
>>> >>
>>> >
>>> >> So thoughts, comments, bad fruit being thrown wanted.
>>> >
>>> >>
>>> >
>>> >>
>>> >
>>> >>
>>> >
>>> >>
>>> >
>>> >>
>>> >
>>> >>
>>> >
>>> >>
>>> >
>>> >> ------------------------------------------------------------------------
>>> >
>>> >>
>>> >
>>> >> _______________________________________________
>>> >
>>> >> Opensim-dev mailing list
>>> >
>>> >> [email protected]
>>> >
>>> >> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>> >
>>> > _______________________________________________
>>> >
>>> > Opensim-dev mailing list
>>> >
>>> > [email protected]
>>> >
>>> > https://lists.berlios.de/mailman/listinfo/opensim-dev
>>> > _______________________________________________
>>> >
>>> > Opensim-dev mailing list
>>> >
>>> > [email protected]
>>> >
>>> > https://lists.berlios.de/mailman/listinfo/opensim-dev
>>> >
>>> >
>>> >
>>> > ------------------------------------------------------------------------
>>> >
>>> > _______________________________________________
>>> > Opensim-dev mailing list
>>> > [email protected]
>>> > https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>
>>> _______________________________________________
>>> Opensim-dev mailing list
>>> [email protected]
>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Opensim-dev mailing list
>> [email protected]
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
> _______________________________________________
> Opensim-dev mailing list
> [email protected]
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
