Micah Cowan wrote:
> Okay, so there's been a lot of thought in the past, regarding better
> extensibility features for Wget. Things like hooks for adding support
> for traversal of new Content-Types besides text/html, or adding some
> form of JavaScript support, or support for MetaLink. Also, support for
> being able to filter results pre- and post-processing by Wget: for
> example, being able to do some filtering on the HTML to change how Wget
> sees it before parsing for links, but without affecting the actual
> downloaded version; or filtering the links themselves to alter what Wget
> fetches.
> However, another thing that's been vaguely itching at me lately, is the
> fact that Wget's design is not particularly unix-y. Instead of doing one
> thing, and doing it well, it does a lot of things, some well, some not.
It does what various people needed. It wasn't an excercise in writing a
unixy utility. It was a program that solved real problems for real
people.
> But the thing everyone loves about Unix and GNU (and certainly the thing
> that drew me to them), is the bunch-of-tools-on-a-crazy-pipeline
> paradigm,
I have always hated that. With a passion.
> - The tools themselves, as much as possible, should be written in an
> easily-hackable scripting language. Python makes a good candidate. Where
> we want efficiency, we can implement modules in C to do the work.
At the time Wget was conceived, that was Tcl's mantra. It failed
miserably. :-)
How about concentrating on the problems listed in your first paragraph
(which is why I quoted it)? Could you show us how would a buch of shell
tools solve them? Or how would a librarized Wget solve them? Or how
would any other paradigm or architecture or whatever solve them?
--
.-. .-. Yes, I am an agent of Satan, but my duties are largely
(_ \ / _) ceremonial.
|
| [EMAIL PROTECTED]
