This is the mail archive of the
kawa@sources.redhat.com
mailing list for the Kawa project.
Re: Java Streams, Kawa ouput, & OutPort
- From: Per Bothner <per at bothner dot com>
- To: Erik Pearson <erik at adaptations dot com>
- Cc: kawa at sources dot redhat dot com
- Date: Tue, 04 Feb 2003 11:52:15 -0800
- Subject: Re: Java Streams, Kawa ouput, & OutPort
- References: <2147483647.1044354056@216-101-171-203.adaptations.com>
Erik Pearson wrote:
Kawa needs to coexist as part of a web pages template processor which
writes html or Jacl output to the servlet response stream independently
of Kawa.
You might consider (at least for new projects) using the KRL or
BRL dialect of Kawa (see the manual) for a nice template processor.
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?
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.
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.
--
--Per Bothner
per@bothner.com http://www.bothner.com/per/