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

[Stephen Woodbridge]

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:
>   
>> 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...)
>

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"
etc.

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.
https://www.avast.com/antivirus