Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!usc!ucsd!ucbvax!CS.UCL.AC.UK!J.Crowcroft
From: J.Crowcroft@CS.UCL.AC.UK (Jon Crowcroft)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: sockets vs. streams
Message-ID: <9009050515.AA00758@ucbvax.Berkeley.EDU>
Date: 2 Sep 90 13:32:52 GMT
References: <9009012315.AA08202@world.std.com>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 28


this reminds me of a great idea from newcastle:
RESCUE (REduced System Call Unix E by gum, i canna recall what the E
was for), an anlaogy with RISC hardware.

i think they got down to about 4 system calls,
you lose all the process ones from the extreme 8th edition idea of
/proc, so processes are created, run and debug with open/read/write
and destroyed with close

remote execution is simple -you use newcastle conenction, and open
/machinename/proc

of course addresses just arent used - just like you dont use inodes
instead of filenames...so all this overloading of things in the name
is unnecassary. all info is in the first component of the path - i.e.
proc is local processes
machinename/proc is remote processes (open /mil.ddn-nic/proc/telnetd,
is a telnet connection to the nic) and so forth
and the talk facility is just a curses version of write to
/machine/dev/tty?.

multicast getsa a bit tricky, i guess you do open("/mil.*", ...)
to give the 3 minute warning:-)

of course, some good things can be taken too far, cant they?

jon.