[mapserver-dev] MapServer 8.0 Config File

[Steve Lime]

Yes, it’s stable although I haven’t changed function signatures for
msLoadMap() in the C code so that probably should happen first.

On Thu, Jul 1, 2021 at 2:07 AM Seth G <sethg at geographika.co.uk> wrote:

> 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
> 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/83810a3c/attachment.html>