[gdal-dev] VSI issue
ari.jolma at gmail.com
Sun Nov 20 06:48:42 EST 2011
On 11/20/2011 01:34 PM, Even Rouault wrote:
> 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.
I meant the WFS error XML that is sent to the client. That needs to go
through the stdout.
>> 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)
VSIFReadL is missing from the Perl bindings - I think it is only in
Python bindings and without any code in the shared interface. I'll add that.
I'll need to review all the VSIF* bindings for the Perl case as I
haven't done that and they are probably unusable now.
>> delete the memory file
More information about the gdal-dev