[mapserver-dev] RFC 125: Support for CONNECTIONOPTIONS in mapfiles

[Lime, Steve D (MNIT)]

The point about validating options is a good one. Namespaces have worked ok for OGC configuration but I don't think they add much value here. Better to just be able to request *all* connection options and know that they are *just* connection options. I think that argues for DATAOPTIONS and PROCESSINGOPTIONS blocks as being available as part of 8.0.

For MapScript I was referring to keeping the API simple with fewer keywords (and dictionaries). The exiting hashObj methods would apply to these new dictionaries of course.

So, at least for me, +1 - carry on...

--Steve

-----Original Message-----
From: mapserver-dev [mailto:mapserver-dev-bounces at lists.osgeo.org] On Behalf Of Even Rouault
Sent: Tuesday, October 01, 2019 4:38 AM
To: mapserver-dev at lists.osgeo.org
Subject: Re: [mapserver-dev] RFC 125: Support for CONNECTIONOPTIONS in mapfiles

Regarding Steve's remark,
> and keep MapScript simpler.

There is nothing to do on mapscript side. hashTableObj objects are
automatically mapped to the relevant dictionary type of the language.
This is similar to the metadata object.

> How about extending the option names to be like:
>
> "GDAL_<driver>_<option_name>" "value"
> "DATA_<option_name>" "value"
> "CONNECTION_<type>_<option_name>" "value"
> etc.

The GDAL_<driver>_<option_name> would actually be a CONNECTION_
And for CONNECTION, you don't need the <type>_

> This would solve both the issues of having a single block, but also
> allowing specificity
> so the code only looks for the prefix that it understands.

That looks more messy to me. If you have several connection options, you
repeat the CONNECTION_ prefix, instead of just putting it once in a block
CONNECTIONOPTIONS. I like the idea of having different blocks for different
purposes. That structures things clearly. And the code is simpler that way,
which is also a good thing.

--
Spatialys - Geospatial professional services
http://www.spatialys.com/en/home/
_______________________________________________
mapserver-dev mailing list
mapserver-dev at lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/mapserver-dev