INCLUDE tag functionality extension... maybe grounds for smallish RFC

[Attila Csipa]

For personal purposes I have somewhat extended the functionality of the 
INCLUDE tag in .MAP files. Originally I needed a way to let certain people 
edit certain parts of the .MAP files, but have them interfere as least as 
possible. In the I ended up a solution that extends the functionality of the 
INCLUDE tag. I've done that way to retain backwards syntax compatibility. The 
old school solution is to have for example

MAP
 NAME 'include'
 EXTENT 0 0 500 500
 SIZE 250 250

 INCLUDE "test_include_symbols.map"
 INCLUDE "test_include_fixedlayers.map"
 INCLUDE "test_include_editablelayers.map"
END

and then you could define different access parameters for the different 
included files but then you would not be able new ones transparently (it 
would be IMO awkward to INCLUDE from INCLUDE-d .MAP files). So the solution 
was to simply check if the INCLUDE parameter is a file or a directory. It 
it's a file, include it regularly, but if it is a directory, execute an 
INCLUDE for all the files present in that dir. To avoid ordering issues 
accross platforms, have the filenames sorted before actual inclusion and 
maintain a number-first naming scheme, much like Apache does.


MAP
 NAME 'include'
 EXTENT 0 0 500 500
 SIZE 250 250

 INCLUDE "conf/symbols/"
 INCLUDE "conf/baselayers.map"
 INCLUDE "conf/enabled_layers/"
END

and in conf/enabled_layers/ you would have files (or softlinks, if we stick to 
the apache naming scheme) like

00-firstlayer.map
10-secondlayer.map
99-lastlayer.map

This also means that for example you can set rights across groups of layers by 
defining rights for a directory, you can add, remove or reorder (!) layers 
with simple file copy/rename commands. The only pitfall so far is the 'too 
easy to break with bad syntax' factor, but that could be remedied by a 
pre-inclusion syntax check (not as easy as it seems on first sight as you 
might be legitimately referencing things that are actually not the included 
file, but this problem exists already with the simple include). Comments ? Do 
you think this patch would be worthwile to merge with the main branch ?