Hi, PostInitialise is extremely important, because it is called at a time when all modules' Initialise has been run. That means, all modules have registered their interfaces and RequestModuleInterface<>() is safe to use in PostInitialise _only_ in a module context. Several existing implementations would be rendered inoperative and actually impossible if there were no PostInitialise.
Melanie Justin Clark-Casey wrote: > Homer Horwitz wrote: >> Ok, I'll try to summarize a bit: >> >> Sean had the great idea to use a dialect-independent way of naming our >> methods: I'll use Init and PostInit :-) >> >> Justin wondered whether we need an Init* method at all or if we just >> could init on first region-add. The benefit of a separate Init + >> PostInit method is, that you can do things before any region has been >> added, but after all the (shared) modules have been initialized. I >> don't know whether that's necessary, but on the other hand, it doesn't >> hurt to have that possibility. It doesn't cost anything, after all. I >> could add some abstract base classes with default implementations, so >> you don't have to add an empty Init-method if you don't need it, but >> that's more or less syntactic sugar... > > Fair enough - though I think I was messing about more with the need for > Init() and Close() at all. But this was > something of a mental experiment - it does make things more readable and > reduce the need for conditions if there are > such explicit methods. > >> >> About the configuration: I don't like the idea of getting the config >> from the scene much, because (at least currently), configuration is >> owned by the server, not by one of its regions/scenes. While I >> understand that some modules won't need a configuration, having to add >> the Nini reference for a fresh region-module doesn't seem too >> difficult to me (the currently available ones already have that >> reference, so no change there). Even if we change that and will have >> region-specific parts of the configuration, the config as a whole will >> still be in the responsibility of the server, not the region, in my >> opinion. > > Also fair enough from my perspective. > >> >> We need a possibility to disable modules (preferably without first >> loading them) without removing the *.dll; and there were some wishes >> about the loader, pro and contra Mono.Addins. I think I'll have a look >> at Mono.Addins (including the IPlugin interface and the >> disable-by-config); it's the one we use already, and I agree that we >> should use only one loader, if possible without having to use too many >> workarounds. If not, ExtensionLoader might win ;-) > > I feel that using ExtensionLoader here is effectively the same decision as > using it everywhere, since in the long term I > really don't think that we want multiple module systems. > >> >> "what happens to avatars that are in a region that you want to restart >> then? are they kicked out first? should they stay?" >> As the region goes down, they can't stay. So, either they will be >> moved away (TP home, maybe?) or they will be kicked out. Kicking them >> out might be the easier thing (and consistent with the SL behavior, >> too); TP home might be difficult if it is the home-region that is >> restarted. >> >> I plan to do the move in an as compatible way as possible; if >> everything works as intended, the "old" modules will continue to work >> for a time. The move will happen in several steps >> - Implementation of the new module system (while keeping the old one >> functional) >> - Marking the old one as deprecated >> - Moving over all the available core region modules to the new system >> - Removing the old region module system >> >> Especially the third part will take some time (not because it is hard, >> I don't think it is, but because we have quite a few modules)... >> >> Thanks for all the contributions :-) >> >> Any last comments? > > Go Homer! > >> >> Cheers, >> Homer >> _______________________________________________ >> 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
