Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!elroy!mahendo!jplgodo!wlbr!scgvaxd!trwrb!aero!obrien
From: obrien@aero.UUCP
Newsgroups: comp.lang.smalltalk
Subject: Communication with the outside world
Message-ID: <17414@aero.ARPA>
Date: Thu, 17-Sep-87 13:19:06 EDT
Article-I.D.: aero.17414
Posted: Thu Sep 17 13:19:06 1987
Date-Received: Sat, 19-Sep-87 16:42:26 EDT
Reply-To: obrien@aero.UUCP (Michael O'Brien)
Organization: The Aerospace Corporation, El Segundo, CA
Lines: 67
Keywords: communication IPC external

As powerful personal engines become increasingly available, Smalltalk-80
is finally starting to come into its own.  However, by entering the
real world, it becomes subject to the laws of the real world: it must
finally be made able to call foreign functions, talk to foreign
processes, etc.

The question of how to carry this out is as yet unresolved.  There
are (at least) two approaches to take:

1) Smalltalk should be as small and simple as possible.  Abstractions
should be simple.  Programming should be fun.

This is the attitude taken by ParcPlace Systems in providing socket
capabilities in their VI2.2/VM1.1 release.  It is a persuasive
argument.  One merely provides a host name and a socket number, and
a ReadWriteStream to goodness-knows-what comes into existence.

2) Networking and IPC are hard no matter what you do.  Low-level
primitives should be provided and people should roll their own
applications.

This is the attitude ParcPlace Systems started to take in the VI2.1/VM1.0
release, where there were (mostly unimplemented) primitives for all
of the UNIX system calls, and about a million caveats in the code.

It is evident that if we could get away with it, approach (1) is
by far the most attractive.  Certainly it is the most seductive.
There are problems, however.

Consider that in the first place, there is no way in the current
implementation to start a remote server under program control.
Servers must be started "by hand" in a terminal window.  fork()/exec()
and wait() do not exist.

Secondly, only client connections can be made by this scheme.  No
provisions are made for doing a listen(), nor, indeed, for handling
wildcard sockets (randomly chosen port numbers).

Given a more atomic primitive set, I claim that it would be possible to
implement a complete RPC/XDR facility, allowing both UDP and TCP sockets
(the current high-level interface supports only TCP connections).
Further, real remote procedure calls could be implemented, allowing
Smalltalk to call procedures written in any other language supporting
RPC and XDR (this includes both Prolog and C, at the least).

One could argue that such generality could be supported by a smaller
number of more general objects, such as is currently done in, say, class
Pen.  Envision, for example:

	socket _ Socket new.
	socket family: Socket AF_INET.
	socket type: Socket UDP.
	socket bindToHost: 'hostname'.  "Subsumes gethostbyname()"

and so forth.  I would have no argument with this, but the class of
primitives would have to be well-thought-out.

Ideally we would want to be able both to call foreign-language functions
and to communicate with (and control!) foreign processes.  Currently this
is possible only in Tektronix' implementation, so far as I know.

Comments?
-- 
--------
Mike O'Brien
obrien@aerospace.aero.org
{sdcrdcf,trwrb}aero!obrien