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

Stephen Woodbridge stephenwoodbridge37 at gmail.com
Mon Sep 30 16:46:10 PDT 2019

On 9/30/2019 7:10 PM, Even Rouault wrote:
> 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:
>>    # data options
>>    "key" "value"
>>    # connection options
>>    # 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,
> 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...)

Hi Guys,

How about extending the option names to be like:

"GDAL_<driver>_<option_name>" "value"
"DATA_<option_name>" "value"
"CONNECTION_<type>_<option_name>" "value"

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.

Just an idea,
   -Steve W

This email has been checked for viruses by Avast antivirus software.

More information about the mapserver-dev mailing list