Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!bloom-beacon!oberon!cit-vax!ucla-cs!zen!ucbvax!DECWRL.DEC.COM!kent From: kent@DECWRL.DEC.COM Newsgroups: comp.protocols.tcp-ip Subject: Re: supdup protocol and local editing Message-ID: <8710132109.AA10463@armagnac.DEC.COM> Date: Wed, 14-Oct-87 04:57:49 EDT Article-I.D.: armagnac.8710132109.AA10463 Posted: Wed Oct 14 04:57:49 1987 Date-Received: Sat, 17-Oct-87 07:21:03 EDT References: <8710132051.AA26315@decwrl.dec.com> Sender: usenet@ucbvax.BERKELEY.EDU Reply-To: "Christopher A. Kent" Organization: The ARPA Internet Lines: 23 Ah. I was off-base -- the work was done at Rutgers, not Arizona. The full reference is DCS-TR-110, "Software Design Issues in the Architecture and Implementation of Distributed Text Editors", Robert N. Goldberg, Dept. of Computer Science, Hill Center for the Mathematical Sciences, Busch Campus, Rutgers University, New Brunswick, NJ 08903. I don't have a copy, so I can't tell you more, but I'll repeat what I recall of the basic premise: the display/user interface portion ran on a PC and accessed the file through a line editor interface, across a 1200 baud line. The PC viewed the whole file in a manner reminiscent of virtual memory. The author developed a concept he called "optimal pre-fetch", based on keystroke analysis of various editors, to allow the PC half to minimize the time the user spent waiting for lines to be fetched across the link. Seems like a good place to start looking, for someone looking to implement this sort of system. I believe that a simple editor makes a better interface for this sort of work than a full-blown remote file system, but it means that youre implementing a fairly special-purpose interface. In this day of faster communication, it may no longer be worth the effort. chris