RFC 16: MapScript WxS Services

[Frank Warmerdam]

Daniel Morissette wrote:
> - There is a typo in the second item of the "Technical Solution" 
> section, this item should refer to WCS and not WMS: "GetCapabilities, 
> DescribeCoverage and GetCoverage calls for **WCS** callable..."

Daniel,

Corrected.

> - There is no mention of SOS. Was it intentionally left out?

I didn't list it because I don't know too much about it, but anything
dispatched through OWSDispatch(), including some stuff I forgot like
GetLegendGraphic and SOS services should also work fine.

> - Should there be a way to pass a custom POST body (string) to 
> OWSRequest.loadParams(), for instance if you want to modify the contents 
> of a WFS XML POST GetFeature call and then have it processed by 
> MapServer? (I didn't look into the code before asking, so maybe the POST 
> body variable is already exposed in OWSRequest in a way that we can set 
> it from MapScript before the call?)
 >

> - Actually, thinking about it some more, loadParams() will require that 
> we have stdin hooks in msIO so that it can read POST request data from 
> stdin when called from MapScript. I wonder if that will be possible with 
> PHP (me thinks there has to be a way, we'll just have to find it). Did 
> you already verify that stdio hooks will be possible with all 
> SWIG-supported languages? Environments such as PHP magically process all 
> the GET and POST data, so I'm not even sure that the POST data is still 
> available via stdin when your PHP script gets executed, the POST data 
> may be in a variable somewhere, I'd have to check.

The msIO_installStdinFromBuffer() and msIO_setStdinBuffer() calls from
MapScript can be used to redirect post body reading from a provided
buffer.  So this gives any mapscript script the opportunity to read
the "post"ed document, possibly process it and pass it on to loadParams().
I'm not too sure how multiple requests with posted input from stdin
would normally be handled in different scripting languages.  So there may
still be deployment issues but I would claim those are beyond my purvue.


> - With respect to generating output, I think it is important to keep the 
> ability to stream to stdout directly and not require the use of output 
> buffers (e.g. msIO_sprintf()/msIO_strcat() as proposed by Tamas), at 
> least for the mapserv CGI case. The main reasons I see for this are:
>   - streaming uses less memory (as pointed in the RFC some GML responses 
> can be quite big)
>   - streaming means faster response time since we start returning data 
> to the client as soon as it's available instead of waiting until the 
> whole response is ready to start returning it (and some large WFS 
> GetFeature responses can take several seconds to construct).

Agreed.  As proposed in RFC 16 the default msIO handlers would continue
to route stdout to ... stdout with no intermediate buffering other than
"sprintf"ing a single msIO_printf() into a working buffer and then fwrite'ing
it.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGF, http://osgeo.org