[gdal-dev] VSI issue

[Ari Jolma]

On 11/20/2011 12:50 PM, Even Rouault wrote:
> Le dimanche 20 novembre 2011 10:04:50, Ari Jolma a écrit :
>> On 11/19/2011 04:24 PM, Even Rouault wrote:
>>>> I found the problem. It is changeset 23022 (by you, Even :), which
>>>> removes support for "stdout" and adds "/dev/stdout" as an alias to
>>>> "/vsistdout/". Simple, but took me a while to find out especially as the
>>>> log message begins "mentions in the doc".
>>> Hum, so it means that under your CGI the stdout file is actually closed.
>>> Because before r23022 /dev/stdout was considered as a regular file and
>>> was opened, but now that /vsistdout/ is used, it directly writes to
>>> FILE* stdout.
>>>
>>> I don't know Apache but perhaps there's an option to leave stdout opened
>>> for the forked process ?
>> I think the correct thing to do is to use "/vsistdout/" in CGI programs,
>> since it works both in older (1.8.0) and newer GDAL (next release).
> Hum, I'm lost. In your first message, you write that using "/dev/stdout" no
> longer works with trunk. But since r23022, "/dev/stdout" is redirected to
> "/vsistdout/", which works. Sounds like there is a contradiction somewhere.

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. 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?)
flush the memory file into VSI stdout (how?)
delete the memory file

Ari

>
>> Ari
>>
>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev