[Opensim-dev] Proposal for a cleanup/correction of the region-module system

[Melanie]

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 at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>> 
>