[Yum] The Future of urlgrabber

[Michael Stenner]

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 at phy.duke.edu
  Box 90305, Durham N.C. 27708-0305