For instance, since OutPort/PrintWriter seems to buffer independently of
the underlying stream it is possible to write to the PrintWriter first
(e.g. via Kawa), then write through the OutputStream via Jacl (or java)
and find that the second write appears in the stream first. In fact, if
output is not forced with a (newline myport) then nothing indeed may be
output at all.
Now some of this can be solved by the servlet handling the response port
interaction with Kawa a little smarter (like flushing the port after all
the scheme-ing is done). However, the main issue, I think, is that there
should be some way of making display, write, etc. atomic in relation to
getting the output through to the underlying stream. A simple flush at
the end of each call would be sufficient.
You means like the autoflush parameter that OutPort and PrintWriter
both support?
The autoflush seems to be tied into the println method of PrintWriter, and
can be forced by calling Kawa's newline function, but this isn't reall the
same thing as flush (well, you know that!)
However, to support more efficient sequences of output, it would also be
good to be able to control flushing behavior (i.e. flush at end of call
or not).
So one question is -- what would be the best method of controlling this?
The problem with actually flushing is that it flushes *all the way*.
That may mean (though I'm not sure) it sends the response-so-far to
the client, which we don't want.
Well there are certainly times when the programmer wants to send output
immediately. E.g. if you are dealing with a page which generates a report
and takes a few seconds, it is nice to have the output fully streamed in a
manner that is under programmer control.
Best, I think, is to call forcePrettyOutput() on the PrettyWriter
which OutPort uses to do the actual buffering. That sends the data
to the underlying Writer without forcing the latter to flush.
Of course then you still need to be able to
A field of the output port that can be controlled and queried via a
couple of functions.
Well, we could add methods to get and set the autoflush parameter,
but I think that's a bad idea, as it encourages inefficient programs.
Better to just add a flush call when you need it.
But then again, writing inneficient programs is the programmer's choice :)