From owner-freebsd-libh Sun Oct 28 4:23:25 2001 Delivered-To: freebsd-libh@freebsd.org Received: from mailgate.originative.co.uk (mailgate.originative.co.uk [62.232.68.68]) by hub.freebsd.org (Postfix) with ESMTP id EE90437B401; Sun, 28 Oct 2001 04:23:16 -0800 (PST) Received: from lobster.originative.co.uk (lobster [62.232.68.81]) by mailgate.originative.co.uk (Postfix) with ESMTP id 29D191D169; Sun, 28 Oct 2001 12:23:14 +0000 (GMT) Date: Sun, 28 Oct 2001 12:23:14 -0000 From: Paul Richards To: Alexander Langer , Josef Karthauser Cc: The Anarcat , "Simon L. Nielsen" , Eric Melville , binup@FreeBSD.org, libh@FreeBSD.org Subject: Re: current project steps Message-ID: <361480000.1004271794@lobster.originative.co.uk> In-Reply-To: <20011028100459.A40262@fump.kawo2.rwth-aachen.de> References: <20011020202153.A76835@FreeBSD.org> <20011026135930.03D1637B406@hub.freebsd.org> <20011026165952.D11804@shall.anarcat.dyndns.org> <20011026221254.A36515@tao.org.uk> <20011026172027.F11804@shall.anarcat.dyndns.org> <20011026223033.A44573@tao.org.uk> <20011027131726.A68253@shall.anarcat.dyndns.org> <20011027210157.D1534@tao.org.uk> <20011028100459.A40262@fump.kawo2.rwth-aachen.de> X-Mailer: Mulberry/2.1.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-freebsd-libh@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --On Sunday, October 28, 2001 10:04:59 +0100 Alexander Langer wrote: > Thus spake Josef Karthauser (joe@tao.org.uk): > > Hi! > >> It sounds to me that libh has its fingers in too many pies. It's not a >> clean API; > > What is your definition of a clean API? One which is independent of all consumers, and is also independent of all possible backends. >> and should be split into several, or rely on others. > > Each library can be interfaced on its own. > - file access (including FTP/HTTP fetch, MD5 and ZIP interface) > - database stuff > - UI layer > - package library > - disk (interface to libdisk etc) > > there are some dependencies, though: e.g. the package library needs the > database lib, for obvious reasons. > > Btw: The abstraction of the place to store the package db information > (you mentioned, e.g. Oracle instead of a local directory) should be > trivial, since everything is handled via calls to functions of > the database lib. Even more, you are using a Database object (C++), > so it's very easy to just write a SQL interfacing Database object. If libh is an installation tool then it shouldn't be concerned with package formats. It should only need to call the API that knows how to install packages. Those packages need not necessarily be in FreeBSD format (either old or new) but could be in any number of different formats and pulled from any number of different repositories. The API would take care of the particalar package format and register all the relevant information into the chosen datastore, but consumers of the API would know nothing about any of this. To do that in libh you'd basically have to implement the sort of API we've been talking about here, but the API should be designed so that it is also pluggable into other applications. It makes more sense to develop it as a separate project, with libh as a consumer, than to develop it as part of libh, so that there is no risk of it having any dependencies on libh or it's design being overly influenced by the specific requirements of libh. Paul Richards FreeBSD Services Ltd http://www.freebsd-services.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-libh" in the body of the message