RFC 16: MapScript WxS Services

[Daniel Morissette]

Frank Warmerdam wrote:
> 
> On a review of the RFC 16 email in my folder, I don't see any +1's.  So
> even taken my own as implicit it appears the RFC has failed to pass.
> 
> Should I take this as a lack of support for the proposal?  Before the
> formal call for votes it seemed to have general support.
> 

Hi Frank,

Sorry for the lack of responses from my part. I think exposing WxS 
Services to MapScript is a great idea, but I got lost with all the 
thread vs msIO discussions and stopped following the discussions until 
this morning... and I missed the call for vote.

See my comments below:

> I have tried to address Tamas's concerns about multi-threading and
> the msIO code, basically by claiming that I'm just using the existing
> mechanism and not making things any worse for multi-threading.  I tried
> to respond to some of SteveW's suggestion regarding msIO filters by
> basically claiming this would be hard to expose properly in mapscript.
> 

My take on the multi-threading vs msIO question is that it should be 
taken to a separate RFC if we can... and without having followed all the 
details it is my understanding that Frank's proposal is just extending 
the existing msIO stuff without making things any worse than they are 
today, and that another RFC to address threading vs IO issues would have 
as many chances of success whether RFC-16 passes or not. Am I right? 
(I'll wait to hear back on this before giving my vote)

More comments after reviewing the RFC:

- 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..."

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

- 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.

- 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).

Well, maybe if we reengineered the code to always use output buffers 
then we could get away with large WFS responses using a method to flush 
the output buffer every n features. Anyway, this question belongs more 
in a new RFC about revamping msIO stuff since the current RFC still 
allows good old streaming to stdout.


Daniel
-- 
Daniel Morissette
http://www.mapgears.com/