[mapserver-dev] Draft proposal for 8.0 - Site Context FIles

[Even Rouault]

> > Since MS 8.0 will include nlohmann/json, perhaps consider a JSON 
> configuration file rather than our historical mapfile-like syntax?
> 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?
You could keep the parsing of the json as an implementation detail in 
the file that parses it and fill a C compatible structure.
>
> >  Regarding using putenv()
> 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?
In a global variable similar to char** environ : 
https://github.com/OSGeo/gdal/blob/bf5289fa6af721cd1ac6a9ff6f215e6340ac4222/gdal/port/cpl_conv.cpp#L1861
>
> On Sat, Apr 3, 2021 at 6:37 AM Even Rouault 
> <even.rouault at spatialys.com <mailto:even.rouault at spatialys.com>> wrote:
>
>     Steve,
>
>     Excellent initiative. A few remarks:
>
>     - Why not calling this a configuration file ? I believe it would
>     be slightly clearer than context
>
>     - 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:
>
>     {
>
>       "env": {
>
>         "#comment": "put some comment here"
>
>         "|MS_MAP_NO_PATH": "true"
>     |
>
>       },
>
>       "maps": {
>
>        "|MAP1": "/opt/mapserver/myapp/map1.map",|
>
>     |  "MAP2": "||/opt/mapserver/myapp/map2.map"|
>
>     ||
>
>       }
>
>     }
>
>     - Regarding using putenv(), I'm not sure this is a good idea in
>     FastCGI mode, according to what is mentioned in
>     http://web.mit.edu/wwwdev/man/man3/FCGI_Accept.3
>     <http://web.mit.edu/wwwdev/man/man3/FCGI_Accept.3>. 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)
>
>     Even
>
>
>     Le 02/04/2021 à 23:19, Steve Lime a écrit :
>>     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
>>     https://github.com/sdlime/mapserver/wiki/MapServer-8.0-Context-File
>>     <https://github.com/sdlime/mapserver/wiki/MapServer-8.0-Context-File>
>>     for more information. Just floating an idea at this point...
>>
>>     --Steve
>>
>>     _______________________________________________
>>     mapserver-dev mailing list
>>     mapserver-dev at lists.osgeo.org  <mailto:mapserver-dev at lists.osgeo.org>
>>     https://lists.osgeo.org/mailman/listinfo/mapserver-dev  <https://lists.osgeo.org/mailman/listinfo/mapserver-dev>
>
>     -- 
>     http://www.spatialys.com  <http://www.spatialys.com>
>     My software is free, but my time generally not.
>
-- 
http://www.spatialys.com
My software is free, but my time generally not.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20210403/c056b6c6/attachment-0001.html>