Date: Sun, 28 Oct 2001 12:23:14 -0000 From: Paul Richards <paul@freebsd-services.com> To: Alexander Langer <alex@big.endian.de>, Josef Karthauser <joe@tao.org.uk> Cc: The Anarcat <anarcat@anarcat.dyndns.org>, "Simon L. Nielsen" <simon@nitro.dk>, Eric Melville <eric@FreeBSD.org>, 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>
next in thread | previous in thread | raw e-mail | index | archive | help
--On Sunday, October 28, 2001 10:04:59 +0100 Alexander Langer <alex@big.endian.de> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?361480000.1004271794>