[Opensim-dev] hypergrid status

[Stefan Andersson]

something worth plsying with, is to stick to the fact that the module is served a configsource, but elaborate a bit on how that source is constructed.
 
The module interface could, for example, expose a 'Get Default Config Source' function that the module manager could use. This could be broken down into "Get Default Config File Name".
 
UNLESS, and this is the interesting part, the module manager is configured to factor config sources from say http or database - nini has a lot of sources. then suddenly, the config source could be a lookup from a database on machine name field and/or module name field.
So, I think one of the reasons we chose nini was to be able to make confuration configurable, so to speak.
Best regards,Stefan AnderssonTribal Media AB Join the 3d web revolution : http://tribalnet.se/ > Date: Thu, 13 Nov 2008 17:00:06 +0000> From: jjustincc at googlemail.com> To: opensim-dev at lists.berlios.de> Subject: Re: [Opensim-dev] hypergrid status> > Diva Canto wrote:> > I did exactly that (or something similar) for the traffic simulation and > > other modules I'm developing for this urban planning startup, Encitra. > > Encitra is a collection of modules, and they all share a common data > > repository that include, among many things, xmls of objects and the ini > > file.> > > > So I don't think you need to do something there. We just need to explain > > better that module config files can be separate. Independent app modules > > like Encitra definitely should not be in OpenSim.ini. Middleware-ish > > things probably shouldn't be there either. Apache at some point started > > separating the config files of its different modules, too. We could do > > something like that.> > Sounds good to me. I suppose my first thought is whether individual modules should (a) be responsible for knowing where > their own config files are or (b) whether OpenSim should tell them where to load them.> > The disadvantage with OpenSim telling them is that they end up having to be in a well known place (perhaps bin/<module > name>/conf or simply bin/conf/<module name>.ini (or .xml). This also envisages moving OpenSim.ini to > bin/conf/OpenSim.ini. The advantage is that having configuration modules always in well known places enhances ease of use.> > The disadvantage with the modules knowing is that it has to be in some well known place for that module which the base > OpenSim may disagree with. However, this is an easier route if modules wish to share the same config file (as your > Encitra modules do).> > Either way, the responsibility for disabling/enabling modules would rest with the master OpenSim.ini (rather than with > individual modules as it does at the moment).> > I had a brief look at Apache configuration but it wasn't obvious to me how it was actually being done (beyond the > standard httpd.conf file, which it sounds like was separated into three but then was put back together again).> > > > > Michael Wright wrote:> >> I guess we should try to come up with some idea what we want from > >> separate config files. As currently it is completely possible and > >> quite easy for modules to load their own ini files by using Nini. Is > >> that enough or do we want more.> >>> >> */Justin Clark-Casey <jjustincc at googlemail.com>/* wrote:> >>> >>> >>> >> I think to some extent this is also pending a revision of the> >> region module system to make it easy to plug in external> >> modules with their own configuration files (OpenSim.ini.example is> >> getting to be a monster). Of course, we've been> >> saying that for ages now - consider it a long feature lead up :)> >>> >>> >>> >> ------------------------------------------------------------------------> >>> >> _______________________________________________> >> Opensim-dev mailing list> >> Opensim-dev at lists.berlios.de> >> https://lists.berlios.de/mailman/listinfo/opensim-dev> >> > > > > > > ------------------------------------------------------------------------> > > > _______________________________________________> > Opensim-dev mailing list> > Opensim-dev at lists.berlios.de> > https://lists.berlios.de/mailman/listinfo/opensim-dev> > > -- > justincc> Justin Clark-Casey> http://justincc.wordpress.com> _______________________________________________> Opensim-dev mailing list> Opensim-dev at lists.berlios.de> https://lists.berlios.de/mailman/listinfo/opensim-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20081113/3773b434/attachment-0001.html>