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"...:-)

Reply via email to