Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 11/03/84 (WLS Mods); site astrovax.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!princeton!astrovax!wls
From: wls@astrovax.UUCP (William L. Sebok)
Newsgroups: net.sources.bugs
Subject: Re: Additions to 4.2BSD tip for xmodem file transfer
Message-ID: <556@astrovax.UUCP>
Date: Tue, 26-Feb-85 16:18:09 EST
Article-I.D.: astrovax.556
Posted: Tue Feb 26 16:18:09 1985
Date-Received: Thu, 28-Feb-85 12:17:26 EST
References: <466@aquila.noao.UUCP>
Organization: Princeton Univ. Astrophysics
Lines: 53

I've wanted to see tip worked over for some time, although tip is already
lightyears ahead of the Bell cu program (even the new BNU one if I read its
man entry correctly).

> Anyone willing to jam the new unix kermit into tip?

I intend to do it differently here.  It seems to me that rather than adding
new commands whenever one wants to interface to a new protocol that one should
be able to use ~p[ut]  and ~t[ake] and have settable state variables to control
the program's behaviour.  ~p and ~t (and tip) should be usable for communication
with other than unix systems with files sent with other than a straight "cat".

The minimum number of these state variables I see would be 4:

1) The character string to be sent to the remote computer at the beginning
of a file sending session.  This would be to prepare the remote host to
accept input.

2) A command string to be executed by the local system to send a file. The
program this would execute could have the file to be sent as its standard input
and the port to the remote system as its standard output.  Alternately some
kind of variables (for example $file and $remote) could be expanded in the
command line into the names of the file and the port to the remote.  This
program could run whatever protocol was desired: kermit, umodem,  a straight
cat, or none of the above.

3) The character string to be sent to the remote computer at the beginning
of a file receiveing session.  This would be to induce the remote host to
send input.

4) A command string to be executed by the local system to receive a file.
The program this would execute could have the the port to the remote system as
its standard input and the file to be received as its standard output.
Alternately, as above, some kind of variables (for example $file and $remote)
could be expanded in the command line into the names of the file and the port
to the remote.  This program could run whatever protocol was desired: kermit,
umodem,  a straight cat, or none of the above.

Thus one can partition the problem in a very unix-like way.  Tip does what it
does well, serving as an interface to the unix system that knows about the
various dialers present and how to allocate and manipulate them.  Tip would
become a front end for these protocol programs that can transfer files reliably
but which do not (and perhaps should not) deal with the complexity of the
time-sharing environment.

Tip also then becomes less tied to be a program for communicating only with
Unix systems.

Sometime, hopefully soon I will post these changes (unless someone beats me
to it).
-- 
Bill Sebok			Princeton University, Astrophysics
{allegra,akgua,burl,cbosgd,decvax,ihnp4,noao,princeton,vax135}!astrovax!wls