<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Verdana;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=EN-US link=blue vlink=purple>
<div class=Section1>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>+1 to that. I’d do config “files” inversion of control style.
Let the module get pushed its config source and use a configurable framework
like Nini as Stefan says to define them.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Mike<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<div>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>
<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
opensim-dev-bounces@lists.berlios.de
[mailto:opensim-dev-bounces@lists.berlios.de] <b>On Behalf Of </b>Stefan
Andersson<br>
<b>Sent:</b> Thursday, November 13, 2008 1:29 PM<br>
<b>To:</b> opensim-dev@lists.berlios.de<br>
<b>Subject:</b> Re: [Opensim-dev] hypergrid status<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal style='margin-bottom:12.0pt'><span style='font-size:10.0pt;
font-family:"Verdana","sans-serif"'>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.<br>
<br>
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".<br>
<br>
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.<br>
<br>
So, I think one of the reasons we chose nini was to be able to make confuration
configurable, so to speak.<br>
<br>
Best regards,<br>
Stefan Andersson<br>
Tribal Media AB<br>
<br>
Join the 3d web revolution : <a href="http://tribalnet.se/">http://tribalnet.se/</a><br>
<br>
<br>
<br>
<br>
<br>
> Date: Thu, 13 Nov 2008 17:00:06 +0000<br>
> From: jjustincc@googlemail.com<br>
> To: opensim-dev@lists.berlios.de<br>
> Subject: Re: [Opensim-dev] hypergrid status<br>
> <br>
> Diva Canto wrote:<br>
> > I did exactly that (or something similar) for the traffic simulation
and <br>
> > other modules I'm developing for this urban planning startup,
Encitra. <br>
> > Encitra is a collection of modules, and they all share a common data <br>
> > repository that include, among many things, xmls of objects and the
ini <br>
> > file.<br>
> > <br>
> > So I don't think you need to do something there. We just need to
explain <br>
> > better that module config files can be separate. Independent app
modules <br>
> > like Encitra definitely should not be in OpenSim.ini. Middleware-ish <br>
> > things probably shouldn't be there either. Apache at some point
started <br>
> > separating the config files of its different modules, too. We could
do <br>
> > something like that.<br>
> <br>
> Sounds good to me. I suppose my first thought is whether individual
modules should (a) be responsible for knowing where <br>
> their own config files are or (b) whether OpenSim should tell them where
to load them.<br>
> <br>
> The disadvantage with OpenSim telling them is that they end up having to
be in a well known place (perhaps bin/<module <br>
> name>/conf or simply bin/conf/<module name>.ini (or .xml). This
also envisages moving OpenSim.ini to <br>
> bin/conf/OpenSim.ini. The advantage is that having configuration modules
always in well known places enhances ease of use.<br>
> <br>
> The disadvantage with the modules knowing is that it has to be in some
well known place for that module which the base <br>
> OpenSim may disagree with. However, this is an easier route if modules
wish to share the same config file (as your <br>
> Encitra modules do).<br>
> <br>
> Either way, the responsibility for disabling/enabling modules would rest
with the master OpenSim.ini (rather than with <br>
> individual modules as it does at the moment).<br>
> <br>
> I had a brief look at Apache configuration but it wasn't obvious to me how
it was actually being done (beyond the <br>
> standard httpd.conf file, which it sounds like was separated into three
but then was put back together again).<br>
> <br>
> > <br>
> > Michael Wright wrote:<br>
> >> I guess we should try to come up with some idea what we want from
<br>
> >> separate config files. As currently it is completely possible and
<br>
> >> quite easy for modules to load their own ini files by using Nini.
Is <br>
> >> that enough or do we want more.<br>
> >><br>
> >> */Justin Clark-Casey <jjustincc@googlemail.com>/* wrote:<br>
> >><br>
> >><br>
> >><br>
> >> I think to some extent this is also pending a revision of the<br>
> >> region module system to make it easy to plug in external<br>
> >> modules with their own configuration files (OpenSim.ini.example
is<br>
> >> getting to be a monster). Of course, we've been<br>
> >> saying that for ages now - consider it a long feature lead up :)<br>
> >><br>
> >><br>
> >><br>
> >>
------------------------------------------------------------------------<br>
> >><br>
> >> _______________________________________________<br>
> >> Opensim-dev mailing list<br>
> >> Opensim-dev@lists.berlios.de<br>
> >> https://lists.berlios.de/mailman/listinfo/opensim-dev<br>
> >> <br>
> > <br>
> > <br>
> >
------------------------------------------------------------------------<br>
> > <br>
> > _______________________________________________<br>
> > Opensim-dev mailing list<br>
> > Opensim-dev@lists.berlios.de<br>
> > https://lists.berlios.de/mailman/listinfo/opensim-dev<br>
> <br>
> <br>
> -- <br>
> justincc<br>
> Justin Clark-Casey<br>
> http://justincc.wordpress.com<br>
> _______________________________________________<br>
> Opensim-dev mailing list<br>
> Opensim-dev@lists.berlios.de<br>
> https://lists.berlios.de/mailman/listinfo/opensim-dev<o:p></o:p></span></p>
</div>
</body>
</html>