[gdal-dev] VSI issue
even.rouault at mines-paris.org
Sun Nov 20 06:34:22 EST 2011
> For CGI "/dev/stdout" works with trunk but it does not work with
> released versions.
> I was confused (I was using two different computers with two different
> setups) and
> as a result my mails were confused, sorry.
> After some more careful testing my final conclusion is the above. The
> only case
> which does not work as expected is "/dev/stdout" with released versions
> (pre r23022) as they
> expect /dev/stdout to be open as you say. In CGI this is not the case.
> But it turns out that while this works, it is not optimal, since in a
> WFS case there may be
> errors during the production of the GML and it should be buffered before
> sending to
> the client - otherwise the error message XML gets mixed up with the GML.
> I'm looking at using VSI memory files for that purpose. If there are no
> errors, then
> the VSI memory file can be flushed to stdout
Errors will go to the stderr flow, not stdout. Errors are likely redirected to
the log file of the http server. So I don't think you will have a mix of GML
output and error messages.
> Probably it is easiest
> done somehow like this:
> create a VSI memory file (does this return a filename?)
> create a GML datasource using that memory file (what's the filename?)
You can combine that step in a single one. Just generate a GML file with a
"/vsimem/somename.gml". It will be implicitely created.
> flush the memory file into VSI stdout (how?)
You can read the content of the file with VSIFOpenL() / VSIFReadL() /
VSIFCloseL() and output it to stdout with whatever Perl offers for that
("print" or something close I'd imagine)
> delete the memory file
> >> Ari
> >> _______________________________________________
> >> gdal-dev mailing list
> >> gdal-dev at lists.osgeo.org
> >> http://lists.osgeo.org/mailman/listinfo/gdal-dev
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
More information about the gdal-dev