[mapserver-dev] MapServer 8.0 Config File
Seth G
sethg at geographika.co.uk
Thu Jul 1 00:07:00 PDT 2021
HI Steve,
I think that should be fine for all the MapScripts.
The C# ones have a second constructor [1], but this could ignore the configObj, or have it as a third parameter.
Is https://github.com/MapServer/MapServer/pull/6303 stable enough to create a SWIG configObj wrapper for testing?
Seth
[1] https://github.com/MapServer/MapServer/blob/e48c5cb1fadec9b3f78b256e121093715b428c1a/mapscript/swiginc/map.i#L44
--
web:http://geographika.co.uk
twitter: @geographika
On Wed, Jun 30, 2021, at 7:54 PM, Steve Lime wrote:
> Seth: Do you think this could be workable?
>
> $config = new mapscript::configObj('path to config file');
> $map = new mapscript::mapObj('my.map', $config);
>
> Seems like we could update the MapScript mapObj constructors to take an optional configObj parameter with default of NULL. Destroying a mapObj doesn't destroy the config (it has a longer scope).
>
> --Steve
>
> On Mon, Jun 21, 2021 at 10:09 PM Steve Lime <sdlime at gmail.com> wrote:
>> Whoops, yes, i had intended to to reply all. Looping -dev back in.
>>
>> On Sun, Jun 20, 2021 at 2:08 PM Seth G <sethg at geographika.co.uk> wrote:
>>> __
>>> Hi Steve,
>>>
>>> I'm not sure if your last reply was also meant to be CCed to the mailing list?
>>> Feel free to add this back to the chain.
>>>
>>> Re the defaults maybe the following approach would be the most flexible:
>>>
>>> - add a function that takes Mapfile1 and Mapfile2 and combines them so any Mapfile2 keywords take precedence, and Mapfile1 is used for any sections not specified. In JS this would be a single applyIf function but I'd imagine it is much harder in C..! The function could be made available via MapScript.
>>> - allow a default Mapfile to be specified in the new config file. The function above would be used to apply settings to any Mapfile loaded via CGI.
>>>
>>> This would get rid of the need for a new DEFAULTS section in the config file requiring object parsing etc. as it would simply be another mapObj. MapScript could then also apply a default Mapfile if required.
>>>
>>
>> Neat idea. Seems like you’d want to load the default first to essentially initialize the mapObj and then the main one over the top of that.
>>
>>>
>>> Re PLUGINS - is the idea the config file would simply replace:
>>>
>>> PLUGIN "mssql"
>>>
>>> With the path to the DLL when loading? E.g.
>>>
>>> PLUGIN "C:/ms4w/Apache/specialplugins/mssql2008.dll"
>>>
>>> It would be good if the same Mapfile would work for both CGI and MapScript, but that would seeminly require a FONTSET-style approach.
>>
>> I agree it would be best. Not sure how to make that happen without requiring changes to scripts with plugins.
>>
>>>
>>> Seth
>>>
>>> --
>>> web:http://geographika.co.uk
>>> twitter: @geographika
>>>
>>>
>>> On Sun, Jun 20, 2021, at 3:12 PM, Steve Lime wrote:
>>>>
>>>>
>>>> On Sat, Jun 19, 2021 at 10:41 AM Seth G <sethg at geographika.co.uk> wrote:
>>>>> __
>>>>> Hi Steve,
>>>>>
>>>>> A few further thoughts.
>>>>
>>>> Thanks!
>>>>
>>>>>
>>>>>
>>>>> 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?
>>>>
>>>> Defaults is better, I agree. By later, do you mean not for 8.0?
>>>>
>>>>>
>>>>> 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 was thinking we’d check the defaults and not write a value if it matched. A copy would retain those values though.
>>>>
>>>>>
>>>>> 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?
>>>>>
>>>>
>>>> My initial thought was if the configObj was present in the mapObj then we’d lookup the value, so it would be required via cgi. If not then it would be taken.”as is”, so no change for mapscript. That check could be done in the END block of the load layer function. The gotcha there is if there was a mapfile that used a plugin and was also used by both mapscript and cgi.
>>>>
>>>>>
>>>>> 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.
>>>>
>>>> Defaults would be an exception to just hashes - although I suppose it would possible to just use a hash there. Maybe there is no constructor. We just provide an method to load the config file into an object but it’s not used for anything but as a convenience reference. That is, a user could look stuff up but it wouldn’t be used for anything else and it wouldn’t provided to the mapObj constructor.
>>>>
>>>>>
>>>>> 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/20210701/348ec8d8/attachment-0001.html>
More information about the mapserver-dev
mailing list