<div dir="auto">More I think about this, I think there shouldn’t be any MapScript impacts. Call it a CGI config file. That doesn’t preclude something in the future but it seems sensible to me to leave that out of scope for now.</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 16, 2021 at 5:21 PM Steve Lime <<a href="mailto:sdlime@gmail.com">sdlime@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">You could certainly store that in one of the hashes "as is" although that's potentially a lot of overhead for storing that limited bit of information, especially since you have to know the path to the configuration file in the first place.<div><br></div><div>It seems to me that the most compelling reason for MapScript to leverage the config file would be for the global section that Seth mentioned. To deal with the globals we need to use the config data as part of the initialization process - so it needs to be part of loading or creating a map object. That way when you initialize the map you would, for example, set the fontset and symbolset attributes based on the global values (if present). Then those could be overridden as necessary. Some of the environment settings around things like a global debug file and level could also be useful in MapScript context.</div><div><br></div><div>So, we'd need to change the msLoadMap() function to take a config parameter. This would be mandatory via the CGI and optional for MapScript. I could see something like this (Perl):</div><div><br></div><div>  $config = new mapscript::configObj('path to config file');</div><div>  $map = new mapscript::mapObj('my.map', $config);</div><div><br></div><div>We could create a few helper methods associated with the config to get at things but the use of the configuration should be pretty much automatic.</div></div><div dir="ltr"><div>  </div><div>--Steve</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 16, 2021 at 9:34 AM Jeff McKenna <<a href="mailto:jmckenna@gatewaygeomatics.com" target="_blank">jmckenna@gatewaygeomatics.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">On 2021-06-16 11:06 a.m., Steve Lime wrote:<br>
<br>
> At the moment this has no impact on MapScript. I was thinking perhaps we <br>
> could add a method to optionally load a config file independently of a <br>
> mapfile. Thoughts?<br>
> <br>
<br>
I believe MapScript impacts was the first comment I had made on this <br>
months ago (and it is mentioned in the RFC draft also).<br>
<br>
For example: PHP SWIG MapScript requires a path to a .php file that <br>
contains all MapServer constants & functions (that is installed as part <br>
of the cmake steps).  For wishlist I'd like to see this new config file <br>
allow to set the path to MapScript's required .php file.<br>
<br>
-jeff<br>
<br>
<br>
<br>
_______________________________________________<br>
mapserver-dev mailing list<br>
<a href="mailto:mapserver-dev@lists.osgeo.org" target="_blank">mapserver-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/mapserver-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/mapserver-dev</a><br>
</blockquote></div>
</blockquote></div></div>