TCP library

[Richard A. O'Keefe]

Martin Wierich <martinw@cs.kun.nl> wrote:
	Our approach differs from the Unicon approach,
	because we give our channels types.
	
	The type constructor for channels has as its argument
	the type of the messages being sent/received.

Yes yes that's fine and it's a wonderful thing to have.
BUT
you have missed my point, which is that for a lot of
applications it is *USEFUL* to have TCP channels that
are just like files, because the protocol the *OTHER*
end of the communication speaks is a *TEXT* protocol.
For just one example, it is quite handy to fire up
gnuplot and send commands to it, and they are text commands.
What if I want a Clean program to "talk" to a tcl/tk program?

Note in particular that in the UNIX world you _already_
have the ability to talk to another program running
independently on the same machine or local shared file
system using named pipes.  The same facility exists in
OS/2 and again permits communication across a network,
but pipes must be called \PIPE\name or \\host\PIPE\name.
and the _same_ DosOpen() function is used to open them
as to open files.  It's even so under Windows, where
CreateNamedPipe() takes names \\.\PIPE\name and gives
you something that the normal ReadFile()/WriteFile()
functions can work with.

Switching from that form of communication to socket
communication in the *other* program is simply a matter
of opening the stream in a different way, not of _using_
it in a different way.  Why should it *have* to be different
in Clean?

Conversely, if you have typed send/receive channels,
why not typed write/read connections to disc files?