[Opensim-dev] Supporting shell environment variables

[Justin Clark-Casey]

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
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>


-- 
Justin Clark-Casey (justincc)
http://justincc.org/blog
http://twitter.com/justincc