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

Homer Horwitz homerhorwitz at googlemail.com
Sun Feb 1 17:51:33 UTC 2009


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



More information about the Opensim-dev mailing list