From owner-freebsd-arch@FreeBSD.ORG Thu Jan 15 10:25:50 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5F86516A4D3 for ; Thu, 15 Jan 2004 10:25:50 -0800 (PST) Received: from VARK.homeunix.com (adsl-68-124-78-95.dsl.pltn13.pacbell.net [68.124.78.95]) by mx1.FreeBSD.org (Postfix) with ESMTP id 610E043D58 for ; Thu, 15 Jan 2004 10:25:47 -0800 (PST) (envelope-from das@FreeBSD.ORG) Received: from VARK.homeunix.com (localhost [127.0.0.1]) by VARK.homeunix.com (8.12.10/8.12.10) with ESMTP id i0FIPWKu026508; Thu, 15 Jan 2004 10:25:32 -0800 (PST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.homeunix.com (8.12.10/8.12.10/Submit) id i0FIPWnS026507; Thu, 15 Jan 2004 10:25:32 -0800 (PST) (envelope-from das@FreeBSD.ORG) Date: Thu, 15 Jan 2004 10:25:32 -0800 From: David Schultz To: Tim Kientzle Message-ID: <20040115182532.GA26149@VARK.homeunix.com> Mail-Followup-To: Tim Kientzle , freebsd-arch@FreeBSD.ORG References: <4004D445.7020205@acm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4004D445.7020205@acm.org> cc: freebsd-arch@FreeBSD.ORG Subject: Re: Request for Comments: libarchive, bsdtar X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2004 18:25:50 -0000 On Tue, Jan 13, 2004, Tim Kientzle wrote: > Request for Comments: libarchive, bsdtar > > PROPOSAL > > Add "libarchive" to the tree, prepare to change the system > tar command to "bsdtar" once it is sufficiently stable. Nice! I'm sure this will be immensely useful when finished. I have a few pseudorandom comments: - Have you considered extending the API such that it is able to efficiently support random access archive formats? This would also be useful for sequential access formats such as tar(5) because the library could be extended to generate an in-core hash index for the archive on the fly, speeding up multiple lookups. Java's ZIP interface does this, for instance. - The HTTP and FTP support in libarchive(3) seems superfluous. Applications that need this feature can use libfetch(3) directly. (I realize that similar libraries such as libcomprex(3) do this, but that doesn't necessarily make it right.) - When this is done, I'm wondering what potential impact it might have on sysinstall and the archive format it uses... (not that I really want to reopen that bikeshed)