Well, maybe I missed saying it in typing.
Pipe the stream from the screen renderer to the zip compressor. Pipe the zip compressor's output
to the browser.
The screen renderer will need to be changed to allow the above. I'm hoping the zip compressor
allows streaming output, or we will have to change the zip compressor as well. Unlikely, because
the authors of the zip compressor should know that any arbitrarily large files could be piped
through the zip compressor.
Jonathon
Adrian Crum wrote:
Maybe I missed something. It sounded like you were proposing sending the
rendered screen directly to the response's output stream. That wouldn't
work because in the two file formats mentioned - xsl-fo and zip - there
needs to be an intermediate document that is parsed and converted.
-Adrian
Jonathon -- Improov wrote:
Adrian,
The rest of my email (of which you quoted a part) highlighted how to
rewire the ScreenFopViewHandler to "output via stream without storing
in large byte array". Yes, the way it is done now can be improved on a
lot. Some PDF screens do take quite a bit of memory.
Using that same method, it would solve your issue with serving up
large files of arbitrary binary data.
Jonathon
Adrian Crum wrote:
Jonathon -- Improov wrote:
Why render to a temp file? Why not simply render to a byte array
like ScreenFopViewHandler (pdf) does? Temp files need cleaning up.
Because there is no way of knowing in advance how large the document
will be. A good example is the entity reference xsl-fo file I created
recently using ScreenFopViewHandler - 16 MB. How many 16 MB Strings
can a server hold? Not very many I would think.
-Adrian
