RFC 16: MapScript WxS Services

[Stephen Woodbridge]

Frank,

On exposing the gdbuffer to mapscript via the msIO functions, what
exactly is getting exposed? Looks like just a pointer to the gd library
image buffer in memory.

How can it be manipulated from mapscript?
I see you example for python. Are planing on adding anything similar for
the other bindings? Have you requested the other binding owners to add
support if you do not plan to?

For example in Perl there is a GD.pm module (see:
http://stein.cshl.org/WWW/software/GD ) for more info, would/will there
be a way to "link up" the buffer with that for additional processing. I
guess my concern is that getting access to the buffer is not real useful
unless there are appropriate tools to do something to the buffer.

I see this raised in the Implementation Issues sections but I requesting
help from the other maintainers would be appropriate if you are unable
to do it yourself.

> Questions:
> 
> 1) Should we be "pushing" handlers instead of installing them and
> losing track of the previous handler? Then we could just pop them
> off.

It seems like pushing, or chaining if you want to have multiple handlers 
editing an io stream, would be appropriate. Or you could have the method 
to install handler and return the previous one and then force the 
programmer to restore it if required, like:

   oldHandler = mapscript.msIO_installStdoutToBuffer()
     ...
   mapscript.msIO_installHandler(oldHandler);

but this is not as nice as pushing and popping handlers or filters. An 
option could be to install filters on the various streams that could 
manipulate the data and even redirect it if required. You are already 
doing that but only for a single handler. Something like:

   sub myfilter {
     ...
   }

   mapscript.msIO_AddFilter(MS_STDOUT, \&my_filter)
     ...
   mapscript.msIO_RemoveFilter(MS_STDOUT, \&my_filter)

   die "err message\n"
     unless mapscript.msIO_PushFilter(MS_STDOUT, \&my_filter)

   oldFilter = mapscript.msIO_PopFilter(MS_STDOUT)

This might get a little too tricky between C code and script code, so 
your proposal might be best. Anyway, just sharing some ideas on this.


Overall performance - I am glad to see your note about testing
performance. If there is any significant impact to performance in the
simple draw shapefile using cgi scenario, then you need to consider
making this an optional build time configuration option. I support
clients drawing 1/2 billion +- map draws a year and have pressure to cut
the draw time in 1/2, so keep this in mind ;)

In general, the rfc is well written and seems reasonably thought out -
good job. Other than my concerns above, I think this sounds good.

-Steve W

Frank Warmerdam wrote:
> Folks,
> 
> I have a first version of the proposal for WxS MapScript Services
> available at:
> 
> http://mapserver.gis.umn.edu/development/rfc/ms-rfc-16-mapscript-wxs-services
> 
> 
> 
> This isn't a call for votes, just for discussion.  The RFC covers:
> 
> o Slight extensions to OWSRequest so it can be used to parse
> arguments from cgi environment arguments (aka call loadParams()).
> 
> o Exposing OWSDispatch() to process OWS requests (WMS, WFS, WCS, etc)
> on a map.
> 
> o Exposing a bunch a of "msIO" functions so scripts can capture
> stdout output from OWSDispatch or anything else that writes through
> msIO.
> 
> The intention is that my work would cover their use in all the SWIG 
> generated mapscript languages.  Additional work would be required to
> implement in PHP but presumably roughly matching what we have.  I
> have already roughly implemented the proposal and tested in Python
> and Perl with good success.
> 
> Best regards,