Hi,
note that I used IScene sxclusively?
Melanie
Stefan Andersson wrote:
> Um, yeah, having 'Scene' as a type in anyhting outside of the Region will
> lead to grief.
>
>
> Suggestion:
>
>
>
> --- OpenSim.Framework: ---
>
>
>
> IGenericModule
>
> {
>
> Initialise();
>
> PostInitialise();
>
> }
>
>
>
> --- OpenSim.Region.Framework: ---
>
>
>
> IRegionModule : IGenericModule
>
> {
>
> OnNewScene();
>
> OnSceneRemoved();
>
> }
>
>
>
> Best regards,
> Stefan Andersson
> Tribal Media AB
>
>
>
>
>
>
> Date: Thu, 26 Feb 2009 12:15:18 +0000
> From: michaelwr...@yahoo.co.uk
> To: opensim-dev@lists.berlios.de
> Subject: Re: [Opensim-dev] Comms Manager
>
>
>
>
>
> I still question if Global modules (that are really providing global
> services) should get any references to Scene/IScene; either by events of
> initialisation calls. If they are providing services, then other
> modules/components should be consumers of them, so only the consumers need
> references to the providers. Not the providers having references to the
> consumers.
>
> But I guess that depends on what we see these global modules as being able to
> do.
>
> --- On Thu, 26/2/09, Stefan Andersson <ste...@tribalmedia.se> wrote:
>
> From: Stefan Andersson <ste...@tribalmedia.se>
> Subject: Re: [Opensim-dev] Comms Manager
> To: "opensim-dev@lists.berlios.de" <opensim-dev@lists.berlios.de>
> Date: Thursday, 26 February, 2009, 11:59 AM
>
>
>
>
> I'm actually with Melanie on this; using the call-back registration and event
> attachment seems so much flexible and cleaner - and more in line with where
> the region modules have been taking us.
>
> Best regards,
> Stefan Andersson
> Tribal Media AB
>
>
>
>
>> Date: Thu, 26 Feb 2009 11:56:31 +0000
>> From: mela...@t-data.com
>> To: opensim-dev@lists.berlios.de
>> Subject: Re: [Opensim-dev] Comms Manager
>>
>> 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: opensim-dev-boun...@lists.berlios.de
>> > [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Stefan Andersson
>> > Sent: Thursday, 26 February 2009 3:00 AM
>> > To: opensim-dev@lists.berlios.de
>> > 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: mela...@t-data.com
>> >> To: opensim-dev@lists.berlios.de
>> >> 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: a...@deepthink.com.au
>> >> > To: opensim-dev@lists.berlios.de; michaelwr...@yahoo.co.uk
>> >> > 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: opensim-dev-boun...@lists.berlios.de
>> >> > [mailto:opensim-dev-boun...@lists.berlios.de] On Behalf Of Stefan
>> >> > Andersson
>> >> > Sent: Thursday, 26 February 2009 2:10 AM
>> >> > To: Michael Wright; opensim-dev@lists.berlios.de
>> >> > 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: michaelwr...@yahoo.co.uk
>> >> > To: opensim-dev@lists.berlios.de
>> >> > 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 <michaelwr...@yahoo.co.uk> wrote:
>> >> > From: MW <michaelwr...@yahoo.co.uk>
>> >> > Subject: Re: [Opensim-dev] Comms Manager
>> >> > To: opensim-dev@lists.berlios.de
>> >> > 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 <mela...@t-data.com> wrote:
>> >> > From: Melanie <mela...@t-data.com>
>> >> > Subject: Re: [Opensim-dev] Comms Manager
>> >> > To: michaelwr...@yahoo.co.uk, opensim-dev@lists.berlios.de
>> >> > 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
>> >> >
>> >> >> Opensim-dev@lists.berlios.de
>> >> >
>> >> >> https://lists.berlios.de/mailman/listinfo/opensim-dev
>> >> >
>> >> > _______________________________________________
>> >> >
>> >> > Opensim-dev mailing list
>> >> >
>> >> > Opensim-dev@lists.berlios.de
>> >> >
>> >> > https://lists.berlios.de/mailman/listinfo/opensim-dev
>> >> > _______________________________________________
>> >> >
>> >> > Opensim-dev mailing list
>> >> >
>> >> > Opensim-dev@lists.berlios.de
>> >> >
>> >> > https://lists.berlios.de/mailman/listinfo/opensim-dev
>> >> >
>> >> >
>> >> >
>> >> > ------------------------------------------------------------------------
>> >> >
>> >> > _______________________________________________
>> >> > Opensim-dev mailing list
>> >> > Opensim-dev@lists.berlios.de
>> >> > https://lists.berlios.de/mailman/listinfo/opensim-dev
>> >>
>> >> _______________________________________________
>> >> Opensim-dev mailing list
>> >> Opensim-dev@lists.berlios.de
>> >> https://lists.berlios.de/mailman/listinfo/opensim-dev
>> >
>> >
>> >
>> > ------------------------------------------------------------------------
>> >
>> > _______________________________________________
>> > Opensim-dev mailing list
>> > Opensim-dev@lists.berlios.de
>> > https://lists.berlios.de/mailman/listinfo/opensim-dev
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev@lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev@lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
_______________________________________________
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
