Java Streams, Kawa ouput, & OutPort

[Erik Pearson]

Hi Per,

Thanks for the quick reply! My comments below:

--On Tuesday, February 4, 2003 11:52 AM -0800 Per Bothner <per@bothner.com> 
wrote:

> 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.

I'm sure that BRL and KRl are great -- but I've got a template processor 
that has been in use for a few years, and, for now at least, the scheme 
needs to co-exist with this other stuff. The template processor is separate 
form the scripting languages, and allows different behaviors to be plugged 
into different tags, etc.



>
>> 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 :)

Seriously, though, it would be nice to avoid this buffer layer. That is why 
the suggestion was to make this a behavior where buffering is enabled by 
default, but having the choice of turning it off.

Of course, in implementations where a scheme port is generated directly in 
the Java layer, as in my case, it is quite possible to enable buffering in 
order to make the stream itself be more effiecient. For interfacing with a 
servelet, the stream could even be a bytearray, which is just dumped into 
the request at the very end of the http session.

What I am looking for, really, is a way to make the invocation of output on 
a port to be predictable -- in that when (display x myport) is executed, it 
is possible to determine, as best I can, that the output has been sent to 
the outside world. I think the interface between Kawa and the world is the 
java stream and the OutPort to which it is provided.

Of course, i can avoid all this mess by just writing via raw java streams 
available through the great define() method of the Environment. However, 
I'd rather keep as much of the Scheme as vanilla as possible.


Thanks,

Erik.

> --
> 	--Per Bothner
> per@bothner.com   http://www.bothner.com/per/
>
>