Stream interfaces

[Dave Harris]

topmind at technologist.com (Topmind) wrote (abridged):
> s = newStream(....)
> s.peekable = true
> s.positionable = false
> s.external = blah
> s.buffered = blah
> s.readAble = true
> s.writeAble = true
> [use the stream now.....]

This doesn't seem very extensible. Here are some things we might 
reasonably expect in a streams library:

   Formatting
       End-user (print, reporting)
       Programmer (display, debug info etc)
       HTML
       XML
       Legacy structured layout
       
   Underlying Data Type
       ASCII
       Unicode
       Multi-byte
       Byte
       Binary (big-endian integers etc)
       Object (Integers etc)
       
   Filtering
       Compression
       Encryption
       Message digests/digital signatures
       Buffering
   
   Sinks/Sources
       Collection
       File
       TCP/IP Socket
       Database

There is a lot going on here. Few applications will need all of it, 
and many shops will want to insert their proprietary or legacy formats 
and algorithms. We need something flexible and extensible.

I agree that a single inheritance hierarchy is not the answer. On the 
other hand, we can't hope to get XML formatting just by writing:

    s.inXml = true

either. I expect we need more delegation. The main thing is to 
separate out the formatting front-end, which needs a rich and probably 
varied API, from the data-sink back-end which can use a much smaller 
and more uniform API. Then we can do buffering etc by means of 
pluggable adaptors, and construct pipelines like:
    XmlStream -> CompressionAdaptor -> SocketStream

This is roughly the approach of the Java library. As far as I know it 
works reasonably well.

  Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
      brangdon at cix.co.uk      |   And close your eyes with holy dread,
                              |  For he on honey dew hath fed
 http://www.bhresearch.co.uk/ |   And drunk the milk of Paradise."