On Mon, Oct 13, 2003 at 03:25:19PM -0400, Jeremy Katz wrote: > Unfortunately, it's pretty clear from my watching things that when you > start sucking libraries (which is what urlgrabber is, really), things > are ugly in almost all cases. eg, problems with libegg getting out of > date in various GNOME apps using it and thus causing problems, having to > do upgrades of six programs because of an exploit in one library > (*cough*zlib*cough*), etc. It also tends to encourage a lack of API > stability which is just as painful for users of your library when they > want to upgrade for bugfixes :/ > > Plus, sucking in copies tends to lead to forks because "well, I've got > the code here, why not make this little change that makes my life > easier". It's far harder to do that when the library is external. OK, those are all excellent points. I'm 99% convinced. > > 2) parallel external > > - not so tidy > > + fewer constraints (change major num when BC breaks) > > + apps get automatic bugfixes with urlgrabber upgrade > > You only do this when you have to. It's not the sort of thing that > should be happening often. It should be planned well in advance and > gone into knowing that you're breaking compatibility against all wants, > hopes and desires :) Just a curiosity. How would this work for a python module? I'm thinking that urlgrabber will take on a structure like this: urlgrabber/__init__.py urlgrabber/<main-file-formerly-"urlgrabber.py"> urlgrabber/keepalive.py urlgrabber/progress_meter.py And then if the parallel external route gets taken, it be done as: urlgrabber2/__init__.py ... Is that what you would have in mind? -Michael -- Michael Stenner Office Phone: 919-660-2513 Duke University, Dept. of Physics mstenner@xxxxxxxxxxxx Box 90305, Durham N.C. 27708-0305
