RFC 16: MapScript WxS Services
Daniel Morissette
dmorissette at MAPGEARS.COM
Fri May 19 11:58:55 EDT 2006
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/
More information about the mapserver-dev
mailing list