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... 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. 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 ;-) "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? Cheers, Homer _______________________________________________ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev