Robert,
All good questions!
Here are some thoughts on this.
1. we all ready have the CGI parameter substitution, but it does require
reading the mapfile to get its validation parameters.
2. we already support includes
3. you would have to read some of the mapfile to get the connection
parameters to access the parameters from a database
4. I like the idea of getting the mapfile from the database, but I think
if I were to go that route, why would I not keep the whole map file in
the database? it would be easy to store it as fragments and parameters
and do the substitution all in the database and just return a text blob
as a mapfile for mapserver to parse. In Postgresql it would be easy to
write a few stored procedures to help manage this and implement it on
the database side of things.
5. Follow the KISS principal. Keep is simple, make the approach
incremental based on the existing code as much as possible
-Steve W
On 10/3/2011 3:59 PM, reholl wrote:
I really like the idea of pulling mapfile resources from RDBMS and URL.
For the URL, I don't think the communications part poses much of a
challenge, as the cURL stuff used in the OWS client can be repackaged. I
did that once to make a mapserv CONNECTIONTYPE as a SOAP client. I can
certainly picture a somewhat generalized mechanism: "fill ANY mapfile
value from some outside resource that delivers a construct of the proper
form/type." These resources might be chained or arranged in branches.
(Does this begin to stray into WPS territory..?) Anything of this
complexity poses a risk to performance and readability. There's
definitely something to be said for the everything-is-right-here aspect
of the mapfile. Does mapserv configuration becomes less 'file' and more
'system.' and with what new maintenance headaches? Or another way to
view it: mapfile syntax becomes a de facto programming language, and we
already have mapscript in numerous flavors. What's the tipping point for
"let's move this complexity into core mapserver"? Given all these
caveats, I'd love to explore this further... Robert Hollingsworth
blammo wrote:
All, Would adding in INCLUDEs from a URL be pushing it too much, as
in: INCLUDE "http://Myserver.com/cgi-bin/myscript.pl"; Could pass in
parameters like so . . . INCLUDE
"http://Myserver.com/cgi-bin/myscript.pl?A=first thing&b=second
thing&c=third thing . . ." bobb >>> "Smith, Michael ERDC-CRREL-NH"
<[hidden email] </user/SendEmail.jtp?type=node&node=6856380&i=0>>
wrote: There is an RFC to have includes come from non-file
connections (databases). It would be another option
http://mapserver.org/development/rfc/ms-rfc-74.html Mike -- Michael
Smith Remote Sensing/GIS Center US Army Corps of Engineers On
10/3/11 2:51 PM, "Stephen Woodbridge" <[hidden email]
</user/SendEmail.jtp?type=node&node=6856380&i=1>> wrote: >One idea
regarding this that you might want to consider is the ability >to
put all the named parameters in an include file, then be able to
>include that file via a CGI parameter. So it might look like this:
> >
View this message in context: Re: Feature wish: Internal mapfile
variables
<http://osgeo-org.1803224.n2.nabble.com/Feature-wish-Internal-mapfile-variables-tp6853853p6856380.html>
Sent from the Mapserver - User mailing list archive
<http://osgeo-org.1803224.n2.nabble.com/Mapserver-User-f1969211.html> at
Nabble.com.
_______________________________________________
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users
_______________________________________________
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users
