Re: [Opensim-dev] Proposal: Change module interface to indicate replacable modules
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, Adama...@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
Re: [Opensim-dev] Proposal: Change module interface to indicate replacable modules
money. -Kyle H On Fri, Jul 10, 2009 at 2:09 PM, Justin Clark-Caseyjjusti...@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
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 Hamiltonaerow...@gmail.com wrote: money. -Kyle H On Fri, Jul 10, 2009 at 2:09 PM, Justin Clark-Caseyjjusti...@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
Re: [Opensim-dev] Proposal: Change module interface to indicate replacable modules
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 Hamiltonaerow...@gmail.com
wrote:
money.
-Kyle H
On Fri, Jul 10, 2009 at 2:09 PM, Justin
Clark-Caseyjjusti...@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
Re: [Opensim-dev] Proposal: Change module interface to indicate replacable modules
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, Adama...@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
