<div dir="ltr">I see what you mean, I just think that gets really complicated and you have to look at a bunch of different contexts to see what's allowed and you're still adding an object, and a more complex one. At least for me, I've tended to use this feature sparingly, for specialized use cases. Others may have different experiences. <div><br></div><div>Note that allowing multiple keywords takes the form of something like (for a scalebar):<div><br></div><div>  URLUPDATE "size|units" # two keywords</div><div>  URLUPDATE "." # all (supported) keywords<br><div><br></div><div>The string is interpreted as a case-insensitive regex. If you have a bunch of styles and only want to tweak one dynamically then this allows that because the expression lives with the object definition - no need to look elsewhere.</div><div><br></div><div>I'd actually want to pull *all* properties that support runtime substitution out of this setup so in the end you end up with relatively few mutable parameters. I mean, it's much easier to use/validate smaller substitution patterns for something like a connection or expression than replacing the whole thing. When Thomas added default values for runsub it really limited the need for this stuff. Still, runsub isn't useful for everything.</div></div><div><br></div><div>--Steve</div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 13, 2021 at 3:24 PM Seth G <<a href="mailto:sethg@geographika.co.uk">sethg@geographika.co.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u><div><div>Hi Steve,<br></div><div><br></div><div>The functionality seems good, however I'm not convinced of the Mapfile syntax to support this.<br></div><div>A few downsides are that It doesn't easily allow global settings, it would add a new keyword to all objects. Also I'm not clear on how to allow modification of multiple keywords within a block.<br></div><div><br></div><div>A possibile syntax alternative (with no regard to ease of implementation!) is to use a combination of the VALIDATION...END block approach and the syntax used for enabling services for OWS requests, similar to <a href="https://mapserver.org/ogc/wms_server.html#web-object-metadata" target="_blank">https://mapserver.org/ogc/wms_server.html#web-object-metadata</a> e.g. "wms_enable_request" "* !GetFeatureInfo"<br></div><div>The block could be named MUTABLE and placed at any level.<br></div><div><br></div><div>For example as a top-level object - this could be set in a MAP..END *or* in a global CONFIG..END<br></div><div><br></div><div>MUTABLE<br></div><div>"layer" "data" # all layer's DATA keywords would be mutable<br></div><div>"scalebar" "* !unitsize" # everything in the scalebar would be mutable *except* for unitsize<br></div><div>END<br></div><div><br></div><div>Then for fine-grained control the same block could be placed in child objects, for example:<br></div><div><br></div><div>LAYER<br></div><div>...<br></div><div>MUTABLE<br></div><div>  "layer" "filter data" # this layer's filter and data keywords would be mutable, but not the DATA clause<br></div><div>  "class" "* !text" # all CLASS keywords are mutable except for TEXT<br></div><div>END<br></div><div>  CLASS<br></div><div>    MUTABLE<br></div><div>      "class" "text" # however the TEXT for this class would be mutable<br></div><div>    END<br></div><div>  END<br></div><div>END<br></div><div><br></div><div>It would make it easier to validate if the properties are supported by run-time substitution and are in the list at <a href="https://mapserver.org/cgi/runsub.html#parameters-supported" target="_blank">https://mapserver.org/cgi/runsub.html#parameters-supported</a><br></div><div>Drawbacks of this syntax- I don't really like having the object name as the key *within" a block e.g. having to set "layer" in a MUTABLE block within a LAYER object, but I can't think of a nicer approach at the moment.<br></div><div>Also having the object in quotes seems..wrong - MUTABLE LAYER "*" END seems more appropriate.<br></div><div><br></div><div>Just some initial thoughts so feel free to consider and discard!<br></div><div><br></div><div><br></div><div>Seth<br></div><div><br></div><div><br></div><div><br></div><div id="gmail-m_7518997478305143788sig62266145"><div>--<br></div><div>web:<a href="http://geographika.co.uk" target="_blank">http://geographika.co.uk</a><br></div><div>twitter: @geographika<br></div></div><div><br></div><div><br></div><div>On Wed, Oct 13, 2021, at 5:29 PM, Steve Lime wrote:<br></div><blockquote type="cite" id="gmail-m_7518997478305143788qt"><div dir="ltr"><div>I have a branch started that adds this functionality (currently for just a scalebar) at <a href="https://github.com/sdlime/mapserver/tree/urlupdate" target="_blank">https://github.com/sdlime/mapserver/tree/urlupdate</a>. It's essentially what I mentioned back in June (time flies). It adds a new attribute called URLUPDATE (more descriptive) that would specify properties that can be updated. The default would be nothing so users would explicitly have to choose what is allowed (from an already limited subset).<br></div><div><br></div><div><div>SCALEBAR<br></div><div>  ...<br></div><div>  URLUPDATE "UNITS|SIZE"<br></div><div>END<br></div></div><div><br></div><div>We would apply the same approach to all relevant objects. So by default no updates would be allowed. I can create a WIP pull request later today...<br></div><div><br></div><div>--Steve<br></div><div><br></div><div><br></div></div><div><br></div><div><div dir="ltr">On Mon, Jun 14, 2021 at 9:46 AM Steve Lime <<a href="mailto:sdlime@gmail.com" target="_blank">sdlime@gmail.com</a>> wrote:<br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Thinking about this, I'd guess I'd propose adding a mutable parameter to structures that support runtime updates. It wouldn't be a boolean but rather a string. Default would be NULL so everything is immutable by default. If a value is present the value would be interpreted as a case-insensitive regex against the allowed attributes. So, for example you could have:<br></div><div><br></div><div>SCALEBAR<br></div><div>  ...<br></div><div>  MUTABLE "UNITS"<br></div><div>END<br></div><div><br></div><div>So, in this case the units of scalebar could be changed via the syntax given in RFC 44 but nothing else.<br></div><div><br></div><div>--Steve<br></div></div><div><br></div><div><div dir="ltr">On Tue, May 18, 2021 at 8:51 AM Steve Lime <<a href="mailto:sdlime@gmail.com" target="_blank">sdlime@gmail.com</a>> wrote:<br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Thanks for the explanation Dan! FWIW I can work up a pull request to illustrate what I was thinking by adding a mutable parameter... I think that can be a simple, easy to understand and explicit approach. --Steve<br></div><div><br></div><div><div dir="ltr">On Tue, May 18, 2021 at 8:47 AM Daniel Morissette <<a href="mailto:dmorissette@mapgears.com" target="_blank">dmorissette@mapgears.com</a>> wrote:<br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>FYI mode=OWS was added to deal with OGC compliance testing which <br></div><div> requires the server to produce an exception in some cases if the <br></div><div> SERVICE/REQUEST parameters are missing... and since MapServer falls back <br></div><div> on the CGI mode by default if SERVICE/REQUESTS are not present then the <br></div><div> only way we could imagine to produce that exception and be compliant was <br></div><div> to add a mode=OWS vendor-specific param in the onlineresource.  More <br></div><div> info here:<br></div><div> <br></div><div> <a href="https://github.com/MapServer/MapServer/issues/2512" rel="noreferrer" target="_blank">https://github.com/MapServer/MapServer/issues/2512</a><br></div><div> <br></div><div> and<br></div><div> <br></div><div> <a href="https://github.com/MapServer/MapServer/issues/2531" rel="noreferrer" target="_blank">https://github.com/MapServer/MapServer/issues/2531</a><br></div><div> <br></div><div> <br></div><div> P.S. I'm following this thread and think it may be a good idea to have <br></div><div> "more opt in and less opt out" for security reasons as long as the <br></div><div> mechanism to handle this is clear and easy to understand, but I don't <br></div><div> have a strong opinion on the proposed changes, that's why I'm staying quiet.<br></div><div><br></div><div> -- <br></div><div> Daniel Morissette<br></div><div> Mapgears Inc<br></div><div> T: +1 418-696-5056 #201<br></div><div> _______________________________________________<br></div><div> mapserver-dev mailing list<br></div><div> <a href="mailto:mapserver-dev@lists.osgeo.org" target="_blank">mapserver-dev@lists.osgeo.org</a><br></div><div> <a href="https://lists.osgeo.org/mailman/listinfo/mapserver-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/mapserver-dev</a><br></div></blockquote></div></div></blockquote></div></blockquote></div><div>_______________________________________________<br></div><div>MapServer-dev mailing list<br></div><div><a href="mailto:MapServer-dev@lists.osgeo.org" target="_blank">MapServer-dev@lists.osgeo.org</a><br></div><div><a href="https://lists.osgeo.org/mailman/listinfo/mapserver-dev" target="_blank">https://lists.osgeo.org/mailman/listinfo/mapserver-dev</a><br></div><div><br></div></blockquote><div><br></div></div></blockquote></div>