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

[Even Rouault]

On lundi 30 septembre 2019 22:51:43 CEST Lime, Steve D (MNIT) wrote:
> Hi Even (and all): I think the RFC looks solid. In terms of implementation I
> was wondering if we might consider a single OPTIONS block so that the
> concept (and keyword) might build some commonality across objects (for
> example, OUTPUTFORMAT could use this). I'd leave METADATA and VALIDATION
> blocks alone. So one could write:
 
> OPTIONS
>   # data options
>   "key" "value"
> 
>   # connection options
>   "FLATTEN_NESTED_ATTRIBUTES" "YES"
> 
>   # processing options
>   "NATIVE_FILTER" "d=234"
> END 
> 
> as opposed to creating a DATAOPTIONS, CONNECTIONOPTIONS and
> PROCESSINGOPTIONS... That would make the mapfile syntax cleaner and keep
> MapScript simpler.

Hum, but how would the code know which of those are for DATA, CONNECTION, 
PROCESSING... ?
For example, GDAL drivers will warn if they are passed an open option they 
don't handle.
With different blocks, we (or any upper-level layer generating mapfile) might 
be able to add more easily validation at a later point rather than if we mix 
everything.
(It's rather unlikely but there's also the risk where a proccessing option 
might have the same name as a driver open option...)

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com