Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site umcp-cs.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!godot!harvard!seismo!umcp-cs!chris
From: chris@umcp-cs.UUCP (Chris Torek)
Newsgroups: net.bugs.uucp
Subject: Re: Possible improvement: wizards opinions wanted.
Message-ID: <435@umcp-cs.UUCP>
Date: Wed, 24-Oct-84 16:31:15 EDT
Article-I.D.: umcp-cs.435
Posted: Wed Oct 24 16:31:15 1984
Date-Received: Fri, 26-Oct-84 03:37:00 EDT
References: <379@west44.UUCP>
Organization: U of Maryland, Computer Science Dept., College Park, MD
Lines: 53

I've always thought that UUCP ought to work like this:

1.  uucp <options> <localfile> <remotefile>

	1.  Create a copy of <localfile> if necessary.
	2.  Get a locked "commands" file, creating one if necessary.
	3.  Put a "send file" command in the last entry in the command
	    file (could use timestamps to keep ordering, whatever).
	4.  Unlock "commands" file.

2.  uux <options> <remotecommand>

	1.  Create a copy of <input to remote command> if necessary.
	2.  Get a locked "commands" file, creating if necessary.
	3.  Put a "send file" command for the input file.
	4.  Put a "send execute" command (possibly by creating a local
	    ``D.systemX'' type file, possibly by just sticking the whole
	    thing into the "commands" file).
	5.  Unlock "commands" file.

3.  uucico

	1.  Get the oldest (smallest mtime) "commands" file and lock
	    it, blocking on the lock until any other users release it.
	    If there are no such files, quit.
	2.  For each command in the file,
	    2a.  Do the command (send a file)
	    2b.  Mark the command as having been completed.
	3.  When all the commands are done, unlink the commands file,
	    then unlock it.
	4.  Start all over again.

	(Or modifications of the above, to try to send files in the
	 order they are queued, with optional ``grading'' too....)

4.  uuxqt - no real changes.

Note that step 2b corresponds pretty closely to your ``mark the
S or R command has having been done already'' idea.  And if you
continue to use lots of little C. files, instead of one big one,
you don't have to worry about how to keep queueing order proper.

The only reason for having mammoth C. files would be to take up
less disk space (but more CPU time, sigh).  [Which do *you* have
more of?  Hm, how about making it runtime configurable? :-)]

Of course, you also need a good locking mechanism.  Sigh...
-- 
(This mind accidently left blank.)

In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (301) 454-7690
UUCP:	{seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@maryland