The general intention is that a WMS or WCS service should be able to
be setup via MapScript. The web request would be turned over to a
MapScript script (Python, Perl, Java, etc) which can then manipulate
the request and a map as needed. Then it can invoke the low level MapServer
request function (ie. GetMap, GetCapabilities), and if desired manipulate
the returned information before returning to the client. This will provide
a means to do customizations such as:

This object is already defined to MapScript in mapscript/swiginc/owsrequest.i
but it seems to lack a means of setting it from cgi arguments or directly
by parsing a provided url. I propose to add the following method on the
OWSRequest:

loadParams();

Loads the parameters from the normal sources (QUERY_STRING env. variable
for instance).

loadParams(constchar*url);

Loads the parameters from the given url portion as would have appeared in
QUERY_STRING if REQUEST_METHOD was GET.

Currently output from functions such as msWMSGetCapabilities() is directed
through the msIO services (in mapio.c), such as msIO_printf(). In order to
capture this output and make it available for further processing it will be
necessary to provide a means for MapScript applications to insert their own
IO handlers of some sort.

Additionally, currently the msIO layer has a concept of io handlers, but
they are global to the application. For non-trivial use of WxS MapScript
services in Java, c# and other multithreaded environments it is desirable
for it to be possible to insert per-thread IO handlers.

Need to make at least current_stdin/stdout/stderr_context variables thread
local. Possibly using the same approach as maperror.c. A new mutex will
be required for this.

Consider thread safe output to shared stdin/stdout/stderr handles for all
threads? ie. protect with a mutex.

We need to provide a convenent way to install “to buffer” and “from buffer”
io handlers.

We need to always use msIO redirection. Currently in the default case of
not using FastCGI, USE_MAPIO is not defined in mapio.h and msIO_printf()
and similar functions are actually just #define’ed to printf(). But if
we want to be able to capture output all the time for MapScript, we will
actually always need the msIO layer. So USE_MAPIO will always have to
be defined.

The msIO_getStdoutBufferBytes() returns a gdBuffer since most language
bindings already have a way of using this as a “array of raw bytes” buffer.
It is normally used for fetched gdImage buffers. But because the msIO
function returns a gdBuffer referring to an internally memory array not
“owned” by the gdBuffer we need to add a owns_data flag.

typedefstruct{unsignedchar*data;intsize;intowns_data;}gdBuffer;

Likewise, each of the language bindings needs to be modified to only
call gdFree() on data if owns_data is true.

some performance testing should be done to verify that USE_MAPIO isn’t
going to slow down normal operations significantly. This is specially
a concern once the mapio.c statics are actually handled as thread local
as each msIO call will need to search for the appropriate thread local
context.

the msIO “buffer” approach is predicated on streaming output results into
a memory buffer. For very large return results this may use an unreasonable
amount of memory. For instance a WFS request with a 250MB response document.
But such results aren’t necessarily reasonable in web services context
anyways.

The set of functions will need to be exposed separately in the PHP bindings.

The msautotest/mspython and python unit tests will be extended with at
least rudimentary testing of a few of these services.

As we have no automated tests for other MapScript languages, no automated
tests will be added, but I will endeavour to prepare simple scripts to test
things. Currently this has been done for Python and Perl MapScript.

This shows a very simple Python MapScript script that invokes a
passed in OWSRequest passed via normal cgi means, but adding a text/plain
content type ahead of the regular content type so we can see the results.
The script could easily have done extra manipulation on the URL parameters,
and on the map object.