From owner-freebsd-current  Thu Jul 18 21:52:19 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id VAA28273
          for current-outgoing; Thu, 18 Jul 1996 21:52:19 -0700 (PDT)
Received: from brasil.moneng.mei.com (brasil.moneng.mei.com [151.186.109.160])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id VAA28259
          for <current@FreeBSD.ORG>; Thu, 18 Jul 1996 21:52:17 -0700 (PDT)
Received: (from jgreco@localhost) by brasil.moneng.mei.com (8.7.Beta.1/8.7.Beta.1) id WAA08396; Thu, 18 Jul 1996 22:47:27 -0500
From: Joe Greco <jgreco@brasil.moneng.mei.com>
Message-Id: <199607190347.WAA08396@brasil.moneng.mei.com>
Subject: Re: various 'fetch' errors
To: jkh@time.cdrom.com (Jordan K. Hubbard)
Date: Thu, 18 Jul 1996 22:47:27 -0500 (CDT)
Cc: imp@village.org, jlemon@americantv.com, current@FreeBSD.ORG
In-Reply-To: <584.837720822@time.cdrom.com> from "Jordan K. Hubbard" at Jul 18, 96 01:13:42 pm
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Sender: owner-current@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> > Yes.  You are being naive.  :-) Let's say I wanted to fetch 10-20
> > things.  And I have microbandwidth to the rest of the world.  I want
> > them to happen sequentially rather than in parallel.  Let's also say I
> > have multiple users that want to do this (say 1-2 each and there are 5
> 
> One of the nice things about UNIX is that you can string existing
> tools together.  Putting all of the above into fetch strikes me as
> overkill in the extreme and you'll never see me add anything as
> ludicrous as this to it! :-)

Ludicrous?  I see.

While I might disagree with that description of the feature request, I 
would agree that it would be better to leverage off of another tool
rather than embedding "cron/at/queue" functionality in the tool.

Except...  we don't have one.  Well, I suppose you could cobble one
together with enough shell or perl programming...  but maybe that
shouldn't count.  

I do think that cron is a good paradigm for this sort of thing.  With
extensions similar to SunOS's queuedefs, it would be adequate to fill
this need.  It also goes a long way to handling resource contention on
slower machines...  because I limit "disk" intensive crontabs to a queue
with one job allowed on Solaria, my disks don't go totally wacko when a
maintenance chore takes longer than I anticipated... indeed I don't even
have to worry about it.

... JG