[gdal-dev] VSI issue

[Ari Jolma]

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
> gdal.Unlink("/vsimem/somename.gml")
> gdal.Unlink("/vsimem/somename.xsd")

Thanks,

Ari