On Mon, 2003-10-13 at 09:58, Michael Stenner wrote: > > Also, it's the same as arguing that you should just suck copies of > > every library into every application or at the minimum that you > > should always do static linking. > > Slow down there. Every library into every application? Saying you > should write _a_ program in python is not the same as saying you > should write EVERY program in python. By no means would a decision to > write urlgrabber for "slurping" imply that all libraries should be > written that way. Yes, I'm somewhat sensationalist -- but being reasonable never seems to get results ;) Also, everything here is generalizations; there are cases where what I describe doesn't happen, but they're the exception rather than the rule. And counting on being the exception tends to be a losing strategy in my experience. 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. > We now have three alternatives on the table: > 1) simple external > + very tidy > - major constraints on the code (preserve backward compat, etc) > + apps get automatic bugfixes with urlgrabber upgrade Well, you obviously start with this in any case. > 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 :) > 3) slurped internal > + very tidy > + no constraints (apps slurp whenevery they want/can) > - no automatic bugfixes - must slurp new version See above :) Cheers, Jeremy
