Joey Hess <[EMAIL PROTECTED]> writes: > Goswin Brederlow wrote: > > I think its a bad idea to say "You want to access to dpkg, programm in > > XXX". All interaction should be via a call to dpkg itself. Also > > modules should be programs by itself and not linked. > > > > dpkg would then call "dpkg-download-ftp" to download a package via > > ftp, or it could call "dpkg-download-apt" to use apt and so on. > > > > That way all modules can be written in any language. They only must > > share a common interface via commandline options, which all programs > > can provide easily. > > Library interfaces can be much richer and let you do a lot of things that > are a royal pain with a command line interface. They also have less overhead. > > C libraries are quite usable from other languages.
For modules that download stuff and many other the interface is real easy and the most time is spend on waiting anyway. There is no need to make a library for those stuff. The problem with libraries is that you can't just create or exchange one easily. You have to know a lot about the structure and code behind it. Also you have to recompile programs to use new libraries. Take binary diffs of deb packages for example. Via a command interface to download packages, its a matter of seconds to write a script that downloads the binary diff of a package and patches the already existing package to the new version and return that for installation. With a library you have to write C (or other language) code, compile that, link that and recompile dpkg to use it. That takes far more time. Of cause for the database that controls whats installed and what state packages are in and so, speed is vital. Esspecially one doesn't want to parse the database again and again. Maybe for that a database interface that starts automatically when first used and keeps runnig for some time in the background would be best. May the Source be with you. Goswin