This page is part of the web mail archives of SRFI 68 from before July 7th, 2015. The new archives for SRFI 68 contain all messages, not just those from before July 7th, 2015.
From: Michael Sperber <sperber@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: finishing output translating stream
Date: Wed, 08 Jun 2005 09:52:01 +0200
> I think I'm beginning to get it---by character conversion buffer, you
> mean stuff left in the "state" variable kept around by the stream
> translation layer, right?
Yes.
> Now, I can see how that may happen in theory---but in practice, aren't
> you likely to always translate as far as possible into the data handed
> to you? (Maybe this should be mentioned in the SRFI.) Because if
> you do, then knowing about a flush is not going to help you if you
> don't get more data along with it (which you don't currently).
In the example like the string packet, I'd think "flushing"
marks that the string is self-contained by that point, so that
the translator can (or should) reset its state to a neutral
position.
Example: suppose my application writes out a log file. I'm
a bit sloppy so the application just opens the log file and
seeks to the end at the startup time, and keep the file open
during execution. The log messages are written out occasionary.
For some reason, I need to store the log file in ISO-2022-JP
format. It is a stateful encoding, so when non-ascii character
sequence appears an escape sequence ESC '$' 'B' is written out,
and when non-ascii character sequence ends another escape sequence
ESC '(' 'B' is written out to mark the state is back to ascii.
It may be possible that the application gets killed without
a chance to cleanup, so I call flush-output-stream every time
after the log message, hoping as much logs remains on the disk
even in the case of accident.
If the translate-proc doesn't know about flush-output-stream,
and a log message happen to end with a non-ascii character,
it won't write out the closing escape sequence ESC '(' 'B'
at the end of log message, for it doesn't know if more non-ascii
character is coming or not. If the application crashes then,
the log file remains in the non-ascii state. Subsequent run
of the applicaion starts adding messages, assuming the file begins
with ascii state---resulting that the first ascii portion of
the new message becomes illegible.
I admit this is just a bad design. Still, the character encoding
stuff is so complicated that I appreciate anything that adds
more certainty and control.
--shiro