Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!rutgers!sri-spam!ames!sdcsvax!ucsdhub!hp-sdd!hplabs!ucbvax!ISI.EDU!cerf From: cerf@ISI.EDU Newsgroups: comp.protocols.tcp-ip Subject: Workstations, SUPDUPl, Windows... Message-ID: <[A.ISI.EDU]12-Oct-87.08:37:28.CERF> Date: Mon, 12-Oct-87 08:37:00 EDT Article-I.D.: <[A.ISI.EDU]12-Oct-87.08:37:28.CERF> Posted: Mon Oct 12 08:37:00 1987 Date-Received: Tue, 13-Oct-87 05:39:15 EDT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The ARPA Internet Lines: 83 Please blame me and not Mr. Mankins if you object to injection of this message into the TCP-IP mailing list. His comments suggest that we ought to reconsider the function of the workstation and PC in relation to mainframes and interconnecting (inter)nets. Where is the proper dividing line between workstation and mainframe? How can context be satisfactorily maintained between these two over connections of varying capacity and delay? Vint ------ Begin forwarded message Received: from BFLY-VAX.BBN.COM by A.ISI.EDU with TCP; Sun 11 Oct 87 22:02:24-EDT Date: 11 Oct 87 21:05:17 EDT (Sun) From: David Mankins To: CERF@a.isi.edu, info-futures@bu-cs.bu.edu Subject: SUPDUP, window systems, slow-links, few packets, fast response Return-Path: Sender: dm@bfly-vax.bbn.com [Mr. Cerf, I'll follow JR's lead and let you decide if this is worth posting to the TCP/IP mailing list.] I hesitate to prolong the SUPDUP discussion on the TCP/IP list, nor do I want to light the flames of window-systems religious wars. However, in discussing window systems, people have seemed to assume that a network window protocol has to work by shipping bulk packages of pixels and mouse movements around (as X v.10 did). As has been pointed out, this is mostly impractical on the ARPANET, or across a serial line (the technologies of the past). But there is an alternative approach: that taken by Sun's News, for example. News ships a high-level description of a window across the network (in the case of News, the description is a Postscript program). I don't know how it deals with mouse-motions and things like menus, but I understand that those are handled by the computer on your desk, too. There are reported to be implementations of News on personal computers communicating with a workstation over a serial line (the technologies of the impoverished present). Well, not only the technologies of the impoverished present. At last year's X forum at MIT, one person asked, ``Is my Cray going to have to pause in calculating a Fourier transform because someone moved a mouse across their desk?''. There are some very rich people who were concerned about the micro-management of pixels pushed onto the host by the early X. In all fairness, I should remark that X v.11 gives the small, cheap computer with the display lots of information that let it save the big, expensive computer (and the network that joins them) from this kind of micro-management. In a way, the News solution is like Stallman's remote-editing protocol: put the responsiveness and user-interface in the $700 hardware on the user's desk, and the computing and file-storage with the big machine across the country (or across the hall). (Stallman's remote editing protocol description is very good, by the way, I second the recommendations it has received on the TCP-IP list. Time still may not have passed it by.) Another approach to the remote-editing/slow link problem was explored by a DEC intern at Project Athena. He looked into combining Stallman's remote-editing protocol with an adaptive encoding data-compression scheme for editing across slow links. I think the computation required to do the data-compression cost more than the transmission time saved. Either that or the summer ended before he finished his work -- I don't recall anything coming out of it. Yet another approach to the slow-link/cheap but sophisticated hardware problem I've seen is this thing from Apple called ``Macworkstation'' or ``Machostconnection'' or something like that. This was a serial-line remote procedure call protocol that permitted your mainframe to invoke Macintosh routines to do menu and icon hunt-and-click computing -- either allowing you to debug your Mac programs in the rich debugging environment of your mainframe, or conceivably allowing your mainframe program to have a Macintosh user-interface. I think there are some third-party products like this now (took 'em long enough). (dm) -------------------- End forwarded message