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
