Channel concept instead of simple Files

[acken@informatik.uni-kl.de]

Hi.

When discussing Files and Locators some time ago, Guy Laden wrote: 
> If we do module Files right, a Locator can be extended into supporting
> URL's with no changes to the module client.

This is certainly an intriguing idea.  But to achive this it is
necessary to put all IO operations (or rather, the objects
implementing this) into a class hierachy, and to allow to add
additional classes to cover new devices or IO channels.  Not a
terribly new idea, agreed.  Unix introduced it a long time ago (file
descriptors), other OS take it even further, e.g. Plan 9.  

Now, what channels are there?  There are some standard channels like
stdin, stdout, stderr, and the null device.  Then there are file
channels, and maybe some kind of memory file (something that behaves
like a file but doesn't write to disk until registration).  Other
possible channels are program arguments (the M2 lib does this), pipes,
sockets (most of all tcp/ip), telnet sessions, ftp, http, etc.  This
list can even be extended by channels handling such exotic devices
like a windowing system or a speech output device.

All those channel types have certain attributes, e.g.
 - read only
 - write only
 - random access
 - interactive
 - has a `length'
 - positionable reading/writing
 - and probably some more
To all channels a reader or writer can be attached.  All those
channels are some form of byte stream.  The source resp. destination
of every channel can be described by some sort of Locator (file name,
host name and port number, etc).

So, instead of creating stand alone Files and Filename modules, I'd
suggest to but them into a framework resp. a class hierachy of
"Channels" and "Locators".  This framework should initially cover
standard IO (stdin, stdout, stderr, null), files, and, possibly,
program arguments.  It should be flexible enough to extend it with
things like TcpIpLocator and TcpIpChannel, FtpLocator and FtpChannel,
etc (maybe even the full range of URL).

The benefit of this approach is an unified IO handling, allowing to
write procedure to operate on any kind of IO channel.  A program
writing to stdout could into one writing into a file by a single
assignment.  Or it could serve a remote telnet connection.  All
channels would share the same code for text based IO (Read/WriteInt
and friends).

The problem, of course, is to design an appropiate class hierachy.
The top of it would be a module defining the abstract types "Locator"
and "Channel".  "FileLocator" and "FileStream" are derived from this
classes.  But with which attributes and methods?  The type Locator has
to provide the type-bound procedures `Old' and `New' to create a new
channel.  Riders (Reader and/or Writer) can then be attached to the
channel, allowing standard IO, regardless of the actual device used.


The IO modules of the M2 DIS implement a flexible channel scheme,
without using OO features of course, so they might serve as an example
of how it could be done.  I don't suggest to copy those modules, but
rather take a look at the basic ideas and to translate them into a
Locator/Channel/Reader/Writer framework similar to the one Sander has
already posted.

Here is an overview of the related M2 IO modules:
(the definition files are part of the ISODefs.zip file in
 incoming/lib) 
  - Input/Output on given channels: 
      TextIO, WholeIO, RealIO, LongIO, RawIO
  - Obtaining and opening channels:
      StdChans, ProgramArgs
  - Device dependent operations: 
      StreamFile, SeqFile, RndFile, TermFile
  - Device independent interface to channels: 
      IOChan
  - Link between channels and new devices:
      IOLink
  - Input/Output on standard channels: 
      STextIO, SWholeIO, SRealIO, SLongIO, SRawIO


Any comments on this?  I'd like to see something like  "Great.  Let's 
do it!"  or  "Here is my proposal for the channel classes."  ;-)

-- mva