Quoting Daniel Barlow (dan@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.