[Opensim-dev] Supporting shell environment variables

[BlueWall]

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