Re: Reorganizing the library
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
Reply to: