On Sat, 14 Aug 2004, Enrico Zini wrote: > One problem of libapt that I see is that it does too many things: access > the APT on-disk database, doing dependency computations, a concurrent > multiprotocol downloader, a rfc822 parser and probably more. This makes > the library complex and hard to work with.
I really don't see how having a stack of somewhat orthogonal things in 1 library is any different from a complexity standpoint of having a stack of orthogonal things in 6 libraries. They don't magically become less interconnected just because they are in different libraries. The current code is as interconnected as it is because it meets some combination of simplicity, necessity and functionality. Unless you are going to directly address that you are not going to get any reduction in complexity or any increase in maintability. Similarly, they aren't any easier or harder to use by seperating them up. Certainly, I agree that the library does many, many things, but the thing at the top of the stack (apt-get and apt-cache) uses every single feature, and the stuff below have absolutely not been built to be general abstract componentry. They exist primarily to support the top. > I'd like to unify a bit all of these efforts, creating some library that > could actually be used and wrapped by other scripting languages, > providing uniform access to various metadata sources and if possible a > more comfortable API than we have now. More than anything, the fact that APT is in C++ is what limits bindings in other languages. For instance there already exist bindings to python for a particular cross section of the internal bits of libapt-pkg and libapt-inst, but it was all carefully hand coded, and was very tedious to make. Unless you intend to change languages as well, you won't get any improvement in that department. C++ is the bane of the automatic binding generators like swig. I think the API is fairly good for C++. If you want something substantially better I think you need to change languages. The python bindings for instance went to some length to bury some of the oddness within native python expressions, native python iterators, etc. So it really is a new API built upon the existing C++ one. Again, this is what makes the bindings tedious. The API exists as it does and is as annoying as it is for the simple reason of speed. There is a heck of alot of data being maintained these days and if you start trading API niceness for shear speed you'll feel it in the GUI's and you'll feel it in apt-get. Computers are fast, but Debian seems to growing at about the same rate. apt-get is no faster today with unstable on my 1Ghz box as it was when I wrote it on my 133MHz box. If anything it is slower :< > I'd start with libapt-pkgindex, so that I can get knowledge on what's on > that on-disk binary index, then possibly using libapt-pkgindex in > libdebtags, and then moving on from there. You should look in cache.sgml, it discusses exactly what is in there. > funding me on this, since it may require quite some time and I > currently don't have an income. Heh, good luck, it took me years to write it in the first place :> Jason
