Thanks for the reply, BlueWall. Response below.
On 24/11/11 02:00, BlueWall wrote:
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.
You learn something new every day :). Yes, it could be a good idea to use that
for some of the config.
* 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
If that's pre-existing syntax then fair enough.
* 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.
It's not a big deal but this kind of thing can crop up in unexpected places. The approach used elsewhere in OpenSim is
to escape with a \, but this might be problematic if people are using Windows paths.
* 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
I guess what I was saying is that one could automatically add every key from EnvConfigSource into [Environment] in the
main config source rather than having to explicitly select them.
This would be more along the lines of other programs which provide something like an Environment hash from which one can
select any env var that happens to be present (e.g System.Environment in .NET, %ENV in Perl, getenv() in PHP). In
OpenSim's case, one would know that everything from the environment is already in [Environment] without having to do any
extra selection work with a somewhat confusing RT_ZONE="" syntax.
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
--
Justin Clark-Casey (justincc)
http://justincc.org/blog
http://twitter.com/justincc
_______________________________________________
Opensim-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-dev
