[streams-standard-discuss] simple-streams

[David Lichteblau]

Quoting Daniel Barlow (dan at telent.net):
> > Problems with the simple stream approach include streams which are
> > buffered in a sense, but in a different way than the original protocol
> > designer hoped they would be.  For example, string streams are special
> > case which users would not be able to implement if the simple streams
> > implementation would have provided for that.
> Can you elaborate on that?  It seems that a basic "read buffer, write
> and empty buffer, seek to position" interface could easily implement a
> string output stream if the write-and-empty-buffer didn't empty it but 
> instead saved it and gave the caller a new buffer (perhaps contiguous)
> to scribble the next block in.  Am I missing something important, or
> does simple-streams not allow this?

Simple streams allow for just that by permitting device level methods to
exchange buffers, yes.

But string simple streams happen to be neither single nor dual channel
simple streams, and users would not be able to define their own instance
flag for this.  I _believe_ this is because string streams are bypassing
external formats and are not bivalent.  (And I hope there are simple
stream experts on this list who can correct me if I'm wrong here.)

But to implementing a bivalent string-stream-like class as a
single-channel-simple stream should be possible.

(Except that when I tried something like this, I failed.  My application
were BLOBs stored in an OO database, and I tried to exchange buffers and
frob the current output pointer.  Finally I gave up and copied the
buffer instead of exchanging it.  So it may well just have been my lack
of understanding for the details...  In a way that may be a point,
however.  Looking at the documentation now trying to recall what I did
back then, I again do not have a clue what DEVICE-EXTEND is for.  In a
new spec for such streams, please make sure that the buffering layer is
as simple as possible. :))


d.