This is the mail archive of the kawa@sources.redhat.com mailing list for the Kawa project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Java Streams, Kawa ouput, & OutPort


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/



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]