[mapserver-dev] MapServer 8.0 Config File

Wed Jun 30 10:54:44 PDT 2021

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
>> https://lists.osgeo.org/mailman/listinfo/mapserver-dev
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20210630/bfafbb18/attachment-0001.html>