[mapserver-dev] MapServer 8.0 Config File

[Seth G]

Hi Steve,

A few further thoughts. 

Maybe DEFAULTS rather than GLOBALS would be a better term for Mapfile site-wide default settings. I think this would be part of a later addition to the config anyway?
When cloning a map or dumping it back out to a Mapfile, I presume any defaults would have to become part of the mapObj/Mapfile itself? Default values for keywords not in a Mapfile are currently copied/output with msCopyMap. 

I think MapScript would need to be able to accept at least a filename to a config file. This could be added to the mapObj constructor e.g. mapObj(char *filename="", char *configfilename=""). 
The main need would be to resolve PLUGIN paths. If these can only be referenced by keys in the config file then it would no longer be possible to work with LAYERs using a PLUGIN in MapScript. 
Alternatively could it be an option to put plugins in their own key/value file and allow this to be referenced in a Mapfile, similar to FONTSET, and maybe allow restricting which paths can be used in the config file?

Finally if the new config file contains sections which can all be accessed via a hashTableObj then it should be fine to provide a SWIG/MapScript interface. However I'm not sure how we'd allow another contructor option cleanly - allowing mapfile, configfile, or configObj to be passed in. 

Seth

--
web:http://geographika.co.uk
twitter: @geographika


On Sat, Jun 19, 2021, at 2:37 PM, Steve Lime wrote:
> 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.
> 
> On Wed, Jun 16, 2021 at 5:21 PM Steve Lime <sdlime at gmail.com> wrote:
>> 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.
>> 
>> 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.
>> 
>> 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):
>> 
>>   $config = new mapscript::configObj('path to config file');
>>   $map = new mapscript::mapObj('my.map', $config);
>> 
>> 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.
>>   
>> --Steve
>> 
>> On Wed, Jun 16, 2021 at 9:34 AM Jeff McKenna <jmckenna at gatewaygeomatics.com> wrote:
>>> On 2021-06-16 11:06 a.m., Steve Lime wrote:
>>> 
>>> > At the moment this has no impact on MapScript. I was thinking perhaps we 
>>> > could add a method to optionally load a config file independently of a 
>>> > mapfile. Thoughts?
>>> > 
>>> 
>>> I believe MapScript impacts was the first comment I had made on this 
>>> months ago (and it is mentioned in the RFC draft also).
>>> 
>>> For example: PHP SWIG MapScript requires a path to a .php file that 
>>> contains all MapServer constants & functions (that is installed as part 
>>> of the cmake steps).  For wishlist I'd like to see this new config file 
>>> allow to set the path to MapScript's required .php file.
>>> 
>>> -jeff
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> mapserver-dev mailing list
>>> mapserver-dev at lists.osgeo.org
>>> https://lists.osgeo.org/mailman/listinfo/mapserver-dev
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org <mailto:mapserver-dev%40lists.osgeo.org>
> https://lists.osgeo.org/mailman/listinfo/mapserver-dev
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20210619/b0f80cd0/attachment.html>