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]

Java "ports" and OutPort


Hi,

I'm hooking Kawa into an existing servlet that also runs Jacl. So far, the experience is very impressive!

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. I'm finding some strange side-effects of the OutPort class, mainly, I believe, having to do with the usage of PrintWriter as the base classs.

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.

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?

Some suggestions are...

A top-level variable which the output functions look at? E.g. output-flush-per-call with #t and #f

A field of the output port that can be controlled and queried via a couple of functions.

A keyword option for each output function to determine the desired behavior

(display "blah blah" myport flush: #t)


I will need to make this change for myself, for practical purposes, in some form or fashion. Would this be a candidate for folding back into the codebase? Is it something that, assuming it is a good idea, Per would rather do at the core level and I pick up from CVS? (Assuming something like this is not already in the pipeline).

Thanks!

Erik Pearson.


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