On 11/23/2011 05:54 PM, Justin Clark-Casey wrote:
Hi BlueWall. Nice work. I do have some comments
* Will this work with all config sections, not just Environment? (e.g.
${DataService|ConnectionString}
The [Environment] section is actually created internally by nini when
the EnvConfigSource is created. It is only a place for the user to set
the keys that will be read from the environment, and that section will
maintain them.
Now, you are able to use any key in it's own section, or any other. You
could do something like...
[Network]
SRV_HOST="http://ascent.bluewallgroup.com";
[InventoryService]
InventoryServerURI = ${Network|SRV_HOST}:8003
[AvatarService]
AvatarServerURI = ${Network|SRV_HOST}:8003
[PresenceService]
PresenceServerURI = ${Network|SRV_HOST}:8003
... We could have been doing that all along. It was already part of Nini.
* Wouldn't it be more natural to use . as the separator rather than |
(e.g. ${DatabaseService.ConnectionString}?
The syntax for the replaceable keys is part of the original Nini. See
the Nini docs for more on that
(http://nini.sourceforge.net/Manual/NiniManual-2.htm#KeyValueExpanding}
. The pipe is also used by Nini to separate terms in a list. See: "3.3
Key Value Lists" @
http://nini.sourceforge.net/Manual/NiniManual-3.htm#AdvancedTopics
* What happens now if somebody actually wants to use a literal
${<something>} string? Is the $ escapable?
It will probably be empty when the keys are expanded. I'll look into
that to see what happens. I can escape it if it's not already doing it.
* Is the [Environment] section really necessary with explicit imports
(which look pretty hacky)? Wouldn't it be simpler to implicitly create
an [Environment] section? I feel this is more along the approach taken
by other languages/systems which make the whole Environment space
available.
Any program would need to select the variables it is interested in at
some point. And in this case, we are opening up the ability for the user
to define the keys that we will fetch the shell values for instead of
having them hard-coded. The first place I thought of putting them was a
separate file, but that is too detached and another ini file is probably
the last thing we need. It seems pretty convenient to place them in a
section. That section should give the keys a significance that they are
treated differently as a group. And haveing them in a section also
connects them in the user's mind to that purpose. The syntax for the pla
might be a little bit awkward first time through using the
${Section|Key} syntax, but that is (and had been forever) Nini's syntax
for expanding keys. We should have been using that by now to define
repetitive values in our configuration files.
A [Environment] section is created internally (in Nini) when the
EnvConfigSource is created and it holds the variables picked from the
shell on the system facing side. And on the OpenSim side, that is the
name of the section that is read to look for keys that will correspond
to shell variables. And we can use that opportunity to set a default
value (although it doesn't yet have the means - WIP) at the key's
definition...
OpenSim ConfigurationLoader
https://github.com/opensim/opensim/blob/master/OpenSim/Region/Application/ConfigurationLoader.cs#L199
Nini EnvConfigSource
https://github.com/BlueWall/Nini-Dev/blob/master/Source/Config/EnvConfigSource.cs#L72
There is probably lots of room for improvement and bug fixes (hopefully
not so many bugs :) I'll especially be watching all the channels for
activity concerning this to fix/add documentation etc. as needed.
Thanks!
BlueWall
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
