Micah Cowan wrote:
I'm not sure what you mean about the linux thing; there are many
instances of runtime loadable modules on Linux. dlopen() and friends are
the standard way of doing this on any Unix kernel flavor.
----
I _thought_ so, but when I asked a distro why they didn't
use this, they said it would require rewriting nearly all currently
existing applications.
My specific complain was against a SuSE distro, that in
in order to load one.rpm, it depended on two.rpm, which depended on
three.rpm, and that on four.rpm, etc. The functionality in "two.rpm"
was to load a library to handle "active directories" which, in my
non-MS, small setup, I didn't need -- and I didn't want to load
the 5-7 supporting packages for AD, since I didn't use them.
BUT, because of static-run time loading, one.rpm would fail if two.rpm
wasn't loaded...and so on and so forth. AFAIK, the same problem
exists on nearly every distro -- because no one bothers to think
that they might not want to load every package on the CD, just
to support local host lookup using...say nscd. Grrrr.
Keeping a single Wget and using runtime libraries (which we were terming
"plugins") was actually the original concept (there's mention of this in
the first post of this thread, actually);
---
Sounds good to me! :-)
the issue is that there are
core bits of functionality (such as the multi-stream support) that are
too intrinsic to separate into loadable modules, and that, to be done
properly (and with a minimum of maintenance commitment) would also
depend on other libraries (that is, doing asynchronous I/O wouldn't
technically require the use of other libraries, but it can be a lot of
work to do efficiently and portably across OSses, and there are already
Free libraries to do that for us).
-----
And perhaps that is the problem. In order to re-use existing
parts of code, rather than adopted them to a "load-if-necessary" type
structure -- everyone prefers to just use them "as is", thus one lib
references another, and another...and so on. Like I think you pull
in "cat", and you get all of the gnu-language libs and tools, which
pulls in alternate character set support, which requires certain
font rendering packages -- and of course, if you are display
alternate characters, lets not forget the corresponding foreign
input methods, and the asian-char specific terminal emulators...etc.
Can I jump off a cliff yet?...ARG! I hack around such problems,
at times, by extracting the 1 run-time library I need, and not the
rest of the package, but then my rpm-verify checks turn up supposed
"errors" because I'm missing package dependencies. Sigh...
If one wanted to add multi-stream support, couldn't the
"small wget" have a check to see if the multi-stream support lib
was present (or not), and if so, set max-streams equal to one that
might yield the basic behavior one might want for the small wget?
Not pushing a particular solution -- I, like you, am just throwing
out ideas to consider...if they've already covered the points I've
raised, feel free to just ignore my ramblings and "carry on"...:-)
Linda
