This is also the case for all the new connector modules.
I'm definitely +1 on solving the problem underlying Melanie's proposal
in some way. Modules are now much more important than they used to be
[and this is a good thing]. Melanie's concrete proposal seems fine.
My feeling is that there's still a lot of things to do in order to get
the most of the module system. And the module system is perhaps the
single most important thing in the entire framework, from a software
engineering perspective.
Teravus Ovares wrote:
> This does not solve the issue with registering interfaces. In the
> map example, the map module was accessed via an interface that it
> registered. Adding the configuration option to turn it off in
> opensim.ini by making the module not register for the interface was
> how diva handled it, however, think in terms of a service provider who
> does some black magic in the module to interface with their systems
> and provides a dll to download. These programmers are not going to
> really want to patch modules to do that. Most want <their custom code
> here> to work touching as little SVN code as possible to limit
> conflicts. Another thing, there isn't really a way to currently order
> the way things load and it would be bad practice to have modules all
> try to re-register themselves over other modules on post init.
>
> Additionally, it would be complicated and error prone for an installer
> or the user to make changes to the order that things load. An
> installer wouldn't even need to change configuration files. As I
> said, this was the purpose of the ReplaceableModules architecture.
> Drop in, and the new functionality is available. This is to make life
> simple for users and service providers.
>
> As people who were in IRC today heard, configuring OpenSimulator these
> days is significantly more difficult then it used to be with cryptic
> error messages that, unfortunately, when I brought them up in IRC,
> nobody knew what to tell me. So, I bumbled around for a few hours
> getting nothing done until I eventually figured out what the problems
> were and committed more clear error messages in the hope that nobody
> else would have to go through that. This forced user configuration
> is unmaintainable.. especially when configuration things change and
> there's no mailing list messages about an update path or even a
> mention that you'll have to re-configure your sim upon updating on the
> mailing list. Ultimately, for people to want to produce and
> distribute modules for OpenSimulator, we need to make it easy for them
> to do so. This is one way that we can make it easy for them.
>
> Regards
>
> Teravus
>
>
> On Fri, Jul 10, 2009 at 10:22 PM, Frisby, Adam<a...@deepthink.com.au> wrote:
>> Suggested change:
>>
>> Some modules need to be configurable (eg, groups needs the groups URL) -
>> therefore, provide a standard way of entering configuration variables into a
>> module that can be set at runtime before the module is fully loaded.
>>
>> As an upside, we could backport that to opensim core, so people can enter
>> opensim.ini settings at first startup. Load the more complicated ones from
>> opensim.ini as a default - but some like the defaultX/defaultY, HTTP port,
>> etc.
>>
>> My suggestion would be something that resembles this in the module code:
>>
>> Public void prestart(IConfig defaults) {
>> IConfig myModuleConfig = new NiniConfig...
>> Configurator config = new Configurator(); // uses STDIO
>>
>> int x;
>> if(!(x = myModuleConfig['MyModule'].GetInteger('foo'))) {
>> // Validation might require better handling...
>> while(x < 0 && x > 100) {
>> x = config.GetInteger("Value of foo?:");
>> }
>> myModuleConfig['MyModule']['x'] = x;
>> }
>> ... wash, rinse, repeat ...
>>
>> myModuleConfig.Save('config/mymodule.ini');
>> }
>>
>> Maybe we can simplify that down with a bit of cleverness and re-usable
>> functions
>> (eg using a lambda or delegate to handle the validation callback)
>>
>> Adam
>>
>>> -----Original Message-----
>>> From: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-
>>> boun...@lists.berlios.de] On Behalf Of Teravus Ovares
>>> Sent: Friday, 10 July 2009 5:05 PM
>>> To: opensim-dev@lists.berlios.de
>>> Subject: Re: [Opensim-dev] Proposal: Change module interface to
>>> indicate replacable modules
>>>
>>> Example:
>>>
>>> Diva created a world map module, but the one in the OpenSimulator
>>> distribution wouldn't let Diva's module run so she had to create a
>>> configuration flag to turn the module in the OpenSimulator
>>> distribution off. Now, there's a complicated configuration option
>>> for the world map module where you have to type out the object
>>> namespace.
>>>
>>> The groups module in OpenSimulator's distribution is a stub. We do
>>> not intend people to use it out of the box. Therefore it makes sense
>>> to have an implicit way to ensure that it doesn't run when there is a
>>> replacement loaded.
>>>
>>> Melanie doesn't think the 'replaceable modules' architecture is
>>> maintainable and so she proposed this idea to solve the 3 goals I had
>>> for it;
>>>
>>> 1. Explicitly declare opensim core developer's intentions for the
>>> module to be replaceable and that we intend on users replacing the
>>> stub with a module that is more full featured
>>>
>>> 2. Be implicit so no configuration files or options need to be managed
>>> by the end user. This makes packaging binaries easier. You tell the
>>> user to download a dll, and put it in the bin folder. No need to
>>> modify the opensim.ini or the config-include folder. This is a step
>>> in the direction of a console module downloader and loader.
>>>
>>> 3. Be resource friendly. Currently even modules that are not running
>>> are loaded in memory. The objects are. They may not be using much
>>> memory.. but they're still there.
>>>
>>> My method of reaching those goals was to create stub projects in
>>> separate dlls where the dll contains only the module. The reason for
>>> it being a single module in the dll is that it can be overwritten with
>>> a dll provided by someone else. I called them the
>>> ReplaceableModules. Melanie doesn't think this is maintainable
>>> though with the number of modules that are stuck in various 'catch
>>> all' dlls. I'm open to other solutions as long as they accomplish
>>> the 3 goals :). Melanie's solution does accomplish those three
>>> goals.
>>>
>>>
>>> Regards
>>>
>>> Teravus
>>>
>>>
>>>
>>> On Fri, Jul 10, 2009 at 6:28 PM, Kyle Hamilton<aerow...@gmail.com>
>>> wrote:
>>>> money.
>>>>
>>>> -Kyle H
>>>>
>>>> On Fri, Jul 10, 2009 at 2:09 PM, Justin
>>>> Clark-Casey<jjusti...@googlemail.com> wrote:
>>>>> Melanie wrote:
>>>>>> The intent of this change is to let a module indicate that it
>>> wishes
>>>>>> it's load to be deferred until all modules have been scanned and
>>>>>> initialized, and to indicate that it wishes to ot be initialized if
>>>>>> another module has already registered it's interface.
>>>>>>
>>>>>> This will allow automatically disabling modules the developer has
>>>>>> marked as "stub" modules without full functionality, so that
>>>>>> replacement 3rd party modules can simply be dropped into the binary
>>>>>> distribution and get picked up and run instead of that stub.
>>>>> Could you give an example of what kind of module we'd be talking
>>> about here? Wouldn't this apply to all modules anyway
>>>>> (since in principle it should be possible to replace anything)?
>>>>>
>>>>> --
>>>>> justincc
>>>>> Justin Clark-Casey
>>>>> http://justincc.wordpress.com
>>>>> _______________________________________________
>>>>> 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
