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

[Steve Lime]

So no MapServer specific implementation, rather just leverage straight CPL
calls.

What about potentially storing the config (structure or potentially json
object) as a global var and then write a few functions to wrap access to
it? So it's not hung off a mapObj.

On Sat, Apr 3, 2021 at 10:05 AM Even Rouault <even.rouault at spatialys.com>
wrote:

>
> > 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>
> 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.  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 for
>> more information. Just floating an idea at this point...
>>
>> --Steve
>>
>> _______________________________________________
>> mapserver-dev mailing listmapserver-dev at lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/mapserver-dev
>>
>> -- 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/08523c47/attachment.html>