Things to do for the Taylor UUCP package.  This list includes some of
my thoughts, but is mostly suggestions from the net.  They are in no
particular order.  Some of the numbers that were in here have been
removed.

2.

John Cowan <cowan@snark.thyrsus.com> says:

>I think you should accept a broader range of time specifications.
>Consider using getdate() (from your handy Usenet news source code)
>with its high-powered yacc parser.

Of course, getdate() accepts a single date, but we want a range.  A
better syntax would be certainly be nice.

4.

John R MacMillan <chance!john@sq.sq.com> mentions the HDB notion of
services; something like this should be added whenever I get around to
writing a version of cu.

6.

T. William Wells <bill@twwells.com> says:

>Something related that might be useful: when calling the other
>system, at certain times I do not want the other system to gain
>control and begin to send files. If that worked, I could call
>them for e-mail without worrying about getting my newsfeed at
>daytime rates. Unfortunately, I can't ask them to batch me at
>night only; my site gets a multibatch. Note that call-timegrade
>would do as well, provided that the other system respects it but
>I have no way to know that, other than by trying it.

9.

Gordon Burditt <gordon@sneaky.lonestar.org> warns about modifications
to the TZ environment variable, to fool uucico into dialing out at an
inappropriate time.

10.

Gordon Burditt <gordon@sneaky.lonestar.org> says:

>(4) Less important, because few people will have this problem, is a 
>port-specific dialcodes file.  Why?  Well, one system I had was connected
>to 2 inside lines "dial 9 for outside line", and one outside line (which
>doesn't want the 9).  A number of the systems called were "inside", so
>you didn't add the 9 on those lines dialing from inside, but you did add 
>"390" to the 4-digit number if you dialed it via "outside".  Also not 
>unheard of are systems with 2 outside lines that are local to different 
>area codes, or one local outside line and one WATS line (which MUST
>have an area code).
>Example:
>	inside-line Dialcodes		outside-line Dialcodes
>	pbx	""			pbx	"390"
>	local	"9"			local	""
>	nyc	"9-1212"		nyc	"1212"

12.

Ralf E. Stranzenbach <ralf@reswi.ruhr.de> says:

>It would be nice to also have the option of running a shell script each time  
>uucico connects/disconnects a systen. I do not mean shell scripts for dial/in.  
>I would like to do some accounting and batching when the connection  
>establishes.

13.

les@chinet.chi.il.us (Leslie Mikesell) writes:

>>local-send /usr/spool/uucppublic !/usr/spool/uucpublic/private
>>
>>The directories are searched from left to right, and the last one to
>>match determines whether the file may be sent or not.  This is
>>slightly more general than NOWRITE, since it permits a public
>>directory within a private directory within a public directory,
>>although probably nobody will ever want that.
>
>Interesting... The obvious enhancement is to generalize to shell-like
>wild cards for the READ/WRITE/COMMANDS entries.

14.

Should there be a way for chat scripts to specify the parity to
generate?  I don't think there's much point to specifying what parity
to accept.

16.

The -j switch to uucp and uux does nothing.  It should print out the
sequence number of the file, and uustat should be written to take that
sequence number and delete the file.

17.

The -b and -s switches to uux are not implemented by uuxqt.

18.

If we are supposed to call a system back, we should do it immediately
rather than merely queuing up an empty command file.

19.

Should there be some way to specify the retry time and the maximum
number of retries using the new configuration scheme?  The retry time
can currently be specified by using a semicolon at the end of a time
string.

20.

Write some protocols that support bidirectional transfers.

James Gardiner says:
> MHSnet has this but with also 3  channels per direction.  Each channel
> sends different size packets.  This alows mail, which is usually smaller,
> to overtake news or big files.  Mail being the more important.
> However, with high speed modems, this is no so important.

21.

Support transfers through systems using uucp and uux.  Implement the
``forward-to'' command to allow control of these transfers.

22.

Add an ftp port type which uses anonymous ftp rather than any of the
UUCP protocols to do file transfers.  This would allow ftp work to be
done late at night.

23.

If we don't permit command execution, we still want to delete the work
files we've been given for the command.

24.

Running uucico as a TCP server doesn't work because only root can bind
a port less than 1024.  This is checked by effective user id, and our
effective user id is always uucp.  If we have saved set user id we
could switch the effective user id to root and then back again;
otherwise we have to not use setuid and start the program as root.
Actually, we could use another program to start as root, bind the
port, and invoke uucico.  One could also just use inetd.  Maybe the
TCP server code should simply be stripped out.

31.

David Nugent: add a -C option to uucico to only call the system if
there was work to do.

32.

It would be nice if uucico could sleep until a line was available.
This is complicated by the possibility of wanting to wait for any of
several different lines, and one would really want some sort of
semaphore function to do it right.  If the available lines could be
sorted, then each could be assigned to a byte in a line lock file.
Looking for a line could be done by sleeping on a read lock on all
possible lines.  Once it came through, write locks would be attempted.
If they all failed, somebody else snuck in, so you would sleep on a
read lock again.  This isn't great because a process could be starved,
but it might be better than nothing.

This could be tied in to uucp and uux, such that they wouldn't
actually fire up uucico unless a line was known to be available; an
additional switch would be used to fire up uucico anyhow (or one could
switch the default behaviour and the switch).

So how do you sort the lines?  You could just use the index in the
port (or Devices) file, but what if multiple ports used the same
physical device?  Hmmm.

33.

David Nugent: allow the minimum wait time to be specified for a
system, such that calls to that system are not made more frequently
than, say, once an hour.

34.

Bob Izenberg: HDB UUCP will retry a call once if it fails.  This can
be done in my system by adding an alternate and repeating the phone
number.  Should there be a configuration parameter to do it in a
simpler way?

36.

David Nugent: add an option to uuxqt to allow a nice value to be
specified.  It's hard to do from a shell script because some systems
don't permit shell scripts to be executed via execl.

43.

David Nugent: it would be nice to be able to set debugging, log, and
statistics files on a site by site basis.

68.

Francois Pinard: attach a name to each alternate and then indicate
which one was used when the connection succeeded.  The name could
simply be an argument to the ``alternate'' command.  Except for the
first alternate, that is.

72.

Monty Solomon: put corrupted files in a special directory (.Corrupt?).

74.

Yanek Martinson: allow each system to independently choose whether to
permit shell execution.

75.

Mike Park: we should accept and Shere=foo message with an alias of the
system we are calling.

78.

Support XCLUDE for port locking.

79.

Support Internet addressing when mailing uuxqt messages.

81.

Marty Shannon: log reason for dial failure (chat-fail string) in
.Status file.

82.

Support restart of failed transfers a la SVR4 UUCP.  Also support SVR4
-U flag.

83.

Switch between 'M' and 'S' correctly in the BNU log file output.

84.
