From owner-freebsd-current Mon Jan 5 03:10:15 1998 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA22760 for current-outgoing; Mon, 5 Jan 1998 03:10:15 -0800 (PST) (envelope-from owner-freebsd-current) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id DAA22755 for ; Mon, 5 Jan 1998 03:10:10 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id DAA10276; Mon, 5 Jan 1998 03:00:32 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd010274; Mon Jan 5 03:00:31 1998 Date: Mon, 5 Jan 1998 02:57:23 -0800 (PST) From: Julian Elischer To: "Jordan K. Hubbard" cc: current@FreeBSD.ORG Subject: Re: Time to retire fetch? In-Reply-To: <4721.883994636@time.cdrom.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk how about making the one program respond to 2 names.. On Mon, 5 Jan 1998, Jordan K. Hubbard wrote: > I just noticed that FTP in -current now supports http:// style > fetches, a feature which seems to have crept in under my nose during > the sync with NetBSD's ftp client. Given that, the questions now in > my mind are: > > 1. Do we want to retire fetch and just use ftp now as our > FETCH_CMD in -current? Would any fetch features be missed > that would also be overtly difficult to merge into the ftp > client? Strengthening one tool rather than putting two > into competition is obviously a worthy goal if it's possible > to do it. > > 2. Do we simply want to ignore this new feature of ftp, perhaps > under the premise that having an ftp client fetch http URLs > is rather counter-intuitive if one is a stickler for naming > conventions, and just go on like we are now? > > 3. Given that ftp probably doesn't deal well with the file:/ > URLs that can also be passed to fetch(1) from the ports > collection, does fetch(1) perhaps want to stick around but > simply become a smaller pre-parsing script which hands its > work off to other tools rather than doing it itself? > > I've no clear preference right now, I'm just musing out loud. > Comments? > > Jordan >