Vote on RFC 31?

[Steve Lime]

Thanks Dan, excellent points and questions. Comments inline...

>>> On 6/20/2007 at 10:44 AM, in message <46794B68.4010505 at mapgears.com>, Daniel
Morissette <dmorissette at MAPGEARS.COM> wrote:
> I took the liberty of doing a few minor edits to fix the Plone warnings 
> that the RFC page was producing, and I also marked the page as 
> published. I hope you don't mind.

No at all, thanks!

> About URLCONFIG, since it's a REGEX, should its value not be delimited 
> by /.../ to be consistent with use of REGEX in other places?

Actually we are not that consistent. TEMPLATEPATTERN and DATAPATTERN
don't use //'s (but could). Actually we could support both notations.

> Also, can you confirm (and perhaps clarify in the rfc) that the 
> URLCONFIG pattern is applied only to the map_* variable name and not to 
> its value? If the filter is applied also to the value then the example 
> in the RFC (URLCONFIG 'scalebar') would not be enough to limit setting 
> only scalebar via URL since the following URL would also pass the test:
> 
> 
> ...map_layer=STATUS+ON+#scalebar

Argh, I made a mistake, the filter is applied to the value not the variable name. 
The function msLoadMapFromURL enforces which "things" can be loaded, that is,
which map_... variables are ok and the lexer enforces syntax on the string
submitted so map_scalebar=UNITS foo STATUS OFF would throw an error.

The more I think about it I don't see any value in the regex on the values 
because you really want to exclude terms and regex doesn't help with that. There
still is value in applying it against the variable name so users could limit which
map_... vars are recognized.

So

URLCONFIG /scalebar/

would stop map_lengend=... from being processed, but would allow map_scalebar.

> Actually, while trying to craft the example above I realized that I 
> didn't know how to specify which layer I wanted to alter. For instance, 
> if I want to update layer named "roads" is it enough to include the 
> "NAME roads" in the value or do I need to use "map_layer_roads" as the 
> URL variable name? An example showing how to do that in the RFC would help.

String loading is for update of an existing object. Any sub-objects referenced
(e.g. a CLASS in a LAYER) would result in a NEW sub-object being created. Since
things like NAMEs can be anywhere in a string (or a file) they aren't useful beyond
simple lookups AFTER the objects are created. 

(IMHO This is an instance where XML mapfiles would be sweet because we could require 
NAME as an attribute (<layer name="foo">) so you could easily check existence while
parsing. We can't do that now.)

So, URL variable names will still require a bit of intelligence to know what object to
update. They would take the identical form as they do now, e.g. map_scalebar
or map_layername. Admittedly URL config is really only useful for modifying the 
highest level objects (e.g. scalebar, layer, legend and so on). Getting at the nested
objects of a layer or a class is rather difficult. Right now the variable naming supports
numeric access since there is no other way to uniquely reference a class or style. To
 get to the 1st style in the 1st class of layer 'foo' you do:

  map_foo_class_0_style_0 or map_layer_5_class_0_style_0

We have to retain that unfortunately. I can't think of a better method, but it does
work. Actually I'd prefer slightly more intuitive syntax like:

map_layer=foo_class=0_style=2

Of course, if layer 'foo' contains no classes then one could add them via URL (if we
wanted to allow it) with:

  map_foo=CLASS ... END CLASS ... END

There is no provision to send a whole mapfile...

I will make a number of changes to the RFC and post here when complete.

Steve

> Daniel
> 
> Steve Lime wrote:
>> Hi all: I'd like to call for a vote on RFC 31. I updated the RFC to try and 
> deal with the points raised. The most significant addition was more 
> elaboration on security related to URL parameter setting. I propose a 
> URLCONFIG parameter addition to the webObj that has dual purposes, 1) to 
> allow URL configuration and 2) to further filter the config string.
>> 
>> The RFC does not address writing to strings as mentioned by Tamas (although 
> I think it's a neat idea). 
>> 
>> Please let me know if there are additional concerns, suggestions or 
> clarifications necessary.
>> 
>> Steve (I'm +1 BTW)
>