<div dir="ltr"><div dir="ltr"><div>> Why not calling this a configuration file ? I believe it would be slightly clearer than context<br></div><div>Of course! I bounced around with a bunch of ideas in my head and missed the most obvious one. I can </div><div><br></div><div>> Since MS 8.0 will include nlohmann/json, perhaps consider a JSON configuration file rather than our historical mapfile-like syntax?</div></div><div>We could, I had thought about it... JSON allows the use of other tools/validators and nlohmann is dead simple. That said, I don't know what the tradeoffs would be in terms of making the JSON configuration object available for use. Could it be hung off the mapObj? Would we have to cpp-ify everything?</div><div><br></div><div>> 

 Regarding using putenv()</div><div>Need to review the exact use of each environment variable to see how they are leveraged. Ideally it wouldn't be necessary. Where is 

CPLSetConfigOption() storing the key/value pairs?</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Apr 3, 2021 at 6:37 AM Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div>
    <p>Steve,</p>
    <p>Excellent initiative. A few remarks:</p>
    <p>- Why not calling this a configuration file ? I believe it would
      be slightly clearer than context</p>
    <p>- Since MS 8.0 will include nlohmann/json, perhaps consider a
      JSON configuration file rather than our historical mapfile-like
      syntax ? This would allow to develop a json-schema for validation.
      Your example would become:<br>
    </p>
    <p>{<br>
    </p>
    <p>  "env": {</p>
    <p>    "#comment": "put some comment here"<br>
    </p>
    <p>    "<code>MS_MAP_NO_PATH": "true"<br>
      </code></p>
    <p>  },</p>
    <p>  "maps": {<br>
    </p>
    <p>   "<code>MAP1": "/opt/mapserver/myapp/map1.map",</code></p>
    <p><code>  "MAP2": "</code><code>/opt/mapserver/myapp/map2.map"</code></p>
    <p><code></code></p>
    <p>  }</p>
    <p>}</p>
    <p>- Regarding using putenv(), I'm not sure this is a good idea in
      FastCGI mode, according to what is mentioned in
      <a href="http://web.mit.edu/wwwdev/man/man3/FCGI_Accept.3" target="_blank">http://web.mit.edu/wwwdev/man/man3/FCGI_Accept.3</a>.  Using GDAL
      CPLSetConfigOption() instead of putenv() and CPLGetConfigOption()
      instead of getenv() would avoid messing with the "environ" global
      variable. (unless I'm wrong our CI doesn't test at all CGI /
      FastCGI ... I'll try to look at adding some testing of this)</p>
    <p>Even</p>
    <p><br>
    </p>
    <div>Le 02/04/2021 à 23:19, Steve Lime a
      écrit :<br>
    </div>
    <blockquote type="cite">
      
      <div dir="ltr">Hi all: Just thinking about ways to make
        configuring MapServer easier for information you can't or don't
        want to manage in mapfiles. Currently that is done via
        environment variables. Another option would be the use of
        config/ini-type file. I've started a draft RFC for something
        I'll call a MapServer context file for the moment. See <a href="https://github.com/sdlime/mapserver/wiki/MapServer-8.0-Context-File" target="_blank">https://github.com/sdlime/mapserver/wiki/MapServer-8.0-Context-File</a>
        for more information. Just floating an idea at this point...
        <div><br>
        </div>
        <div>--Steve</div>
      </div>
      <br>
      <fieldset></fieldset>
      <pre>_______________________________________________
mapserver-dev mailing list
<a href="mailto:mapserver-dev@lists.osgeo.org" target="_blank">mapserver-dev@lists.osgeo.org</a>
<a href="https://lists.osgeo.org/mailman/listinfo/mapserver-dev" target="_blank">https://lists.osgeo.org/mailman/listinfo/mapserver-dev</a>
</pre>
    </blockquote>
    <pre cols="72">-- 
<a href="http://www.spatialys.com" target="_blank">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
  </div>

</blockquote></div></div>