On Tue, Nov 24, 2009 at 12:00:21AM +0100, Julian Andres Klode <[email protected]> was heard to say: > On Mon, Nov 23, 2009 at 07:41:42AM -0800, Daniel Burrows wrote: > > Hm. I'm pretty skeptical about writing a system tool like this in a > > high-level language. Both from the point of view of dependency > > fragility and because you want it to be easy to access the functionality > > from other languages. In fact, I've occasionally wondered if it makes > > sense for the public API of an apt successor to be pure C (even if the > > implementation is C++ behind the scenes). C++ ABIs are obnoxiously > > fragile and poorly defined, for one thing. (although very convenient if > > you're writing in C++) > > Vala compiles to C, and provides a C-API comparable to other GObject libraries > such as GTK+. You get a C library with a header file and everything, and you > can write applications using the library in C. For now, dependencies are > libglib2.0-0 > libgee1 (container classes) > libsoup2.4-1 (HTTP/HTTPS acquire part) > > The latter one could be replaced with a limited http downloader for embedded > systems; which only depends on libglib2.0-0.
Ah, I didn't get that from a quick Google search. That makes more sense. > > > Some kind of a roadmap: > > > > > > * identify stuff we don't use anymore and remove it, eg. > > > apt-pkg/vendor*, apt-inst/database*, apt-inst/deb/dpkgdb*. > > > * drop compatibility for GCC < 4.3, and other stuff older > > > then what is included in Debian Lenny. > > > * rework the buildsystem using CMake > > > > (ABI breaking stuff) > > * Write a more organized download system. (see below) > > > > Maybe also figure out a style guide for C++ going forwards (e.g., > > recommend not using exceptions, using smart pointers, using STL > > containers, etc). > Or copy Google's style guide and remove the stuff we don't like; and > adjust it to our coding standards. Their style guide is very complete, > and thus a good base. Sure. > > In aptitude, I have built an internal API that provides a low-level > > URI downloader running in a background thread. Currently it's based on > > Acquire, but with a little work it could replace Acquire instead > > (at first glance, the Acquire main loop and the download queue management > > would need to be incorporated). I think it's a good example of the > > simple interface I'm thinking about, anyway: > > > > http://hg.debian.org/hg/aptitude/head/file/b8a7fc61b13c/src/generic/apt/download_queue.h > > I'm missing a few parts like a target filename, but maybe this is defined > somewhere else? There are a few things that would need to be added. In aptitude, the target filename is generated as a temporary name and passed out as a return value via the completion callback. A generic version of this would probably specify the file as a parameter to queue_download(). The status callbacks are also incomplete -- it needs at least a way to provide some sort of message string giving the current status. Daniel _______________________________________________ Aptitude-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/aptitude-devel
